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

Fabian Lange lange.fabian at gmail.com
Wed Aug 27 14:02:00 UTC 2014


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



More information about the core-libs-dev mailing list