Impact of code difference in Collection#contains() worth improving?

[Martin Buchholz]

The ArrayList version saves one byte of bytecode, and is therefore very
slightly better.  We should bless that version and use it consistently.


javap -c -private java.util.ArrayList | grep -A10 'boolean.*contains'
  public boolean contains(java.lang.Object);
    Code:
       0: aload_0
       1: aload_1
       2: invokevirtual #31                 // Method
indexOf:(Ljava/lang/Object;)I
       5: iflt          12
       8: iconst_1
       9: goto          13
      12: iconst_0
      13: ireturn



On Wed, Aug 27, 2014 at 7:02 AM, Fabian Lange <lange.fabian at gmail.com>
wrote:

> Hi all,
> I have been involved recently in some theoretical or nonsensical
> discussions about microbenchmarking, jit compiling assemblies and so
> fort.
> One example was LinkedList vs ArrayList.
>
> What I noticed is that those two have a different implementation for
> contains():
>
> ArrayList:
>
>     public boolean contains(Object o) {
>         return indexOf(o) >= 0;
>     }
>
> LinkedList:
>
>     public boolean contains(Object o) {
>         return indexOf(o) != -1;
>     }
>
> Logically this is of course identical due to the contract of contains
> which returns either -1 or the >=0 index of the element.
>
> This code has been like this almost forever, and I was wondering if
> this actually makes a difference in CPU cycles.
>
> And in fact this code compiles into different assembler instructions.
> The array list does a test against 0 and conditional move, while the
> linked list does a jump equals on -1.
>
> Again that is not surprising, because the actual java source is
> different. But I wonder if both options are equally good in cold
> performance and when jitted based on parameter values.
>
> Wouldn't one implementation be better than the other? And why is not
> the "better" implementation taken in both classes (and maybe other
> Collections which use indexOf) ?
>
> Is the answer that this has always been like this and the benefit is
> not worth the risk of touching ancient code?
>
> And if not for performance, would code clarify and similarity be an
> argument?
>
> (this message was posted to jdk8-dev initially, thanks to Dalibor
> Topic for the pointer to this list)
>
> Fabian
>