Is calling equals() on the same instance faster than on changing instances?

Question

Is there any reason that:

public void test(Object object) {
    for (Object other : otherObjects) {
        object.equals(other);
    }
}

could be faster than:

public void test(Object object) {
    for (Object other : otherObjects) {
        other.equals(object);
    }
}

( as equals() is called on the same object in the first example?)

Related to Is CONSTANT.equals(VARIABLE) faster than VARIABLE.equals(CONSTANT)? and Interview : Java Equals.

Answer 1

There should be no difference for objects that implement equals in a way that it is useful (say, java.lang.String or java.lang.Integer).

However, you can't generalize this, because corner cases do exist. For example, if object passed in implements equality through identity, i.e.

@Override
public boolean equals(Object other) {
    return other == this; // identity equality
}

while objects in your collection perform a type check before returning a value, the first approach will require fewer CPU cycles, translating into faster execution.

A quick performance benchmark of this corner case shows an improvement of about 25% (45 ms to 34 ms).

Note that this is only a corner case, not a general rule. You should not rely on it for performance optimizations.

Answer 2

This question has a lot of dimensions; let's address them one by one:

Yes, polymorphism could translate into performance gains. Option 1 calls the same method repeatedly. Option 2 could theoretically invoke a different equals implementation during each call. Thus Option 1 becomes subject to "JIT" compilation much earlier.

But let's look into the "practical" relevance of the whole thing:

Looking at compiled bytecode is interesting; but not really that helpful in the real world; as there are two cases:

• bytecode is just exected a few times - JIT doesn't kick. Does it make a difference then, if that method needs 500 or 600 ns to finish?
• bytecode is executed often enough for the JIT to work on it. Then you have no idea what will come out of that anyway.

Beyond that:

• if you would be concerned about performance in the real world ... then you use neither of those two options; because in the real world, you would make sure that this incoming collection would be a set. If contains() is such a common operation in your code that you start worrying about option 1 vs option 2, then you would for sure go for O(1) set operation instead!
• and as we have seen, option 1 might occasionally perform better. And: it is easier to read (much less surprising than option 2). And it has a slightly different probabilities regarding NPEs.

Long story short: all the arguments are in favor for option 1. Clear winner here!

Finally: of course, benchmarking this is an interesting exercise; but keep in mind: correct benchmarking is hard!

Answer 3

No there is no reason. This is the equals() method from class Object

public boolean equals(Object obj) {
    return (this == obj);
}

Take this code

public class TestClass {
    private Object[] otherObjects;

    public void test1(Object object) {
        for (Object other : otherObjects) {
            object.equals(other);
        }
    }

    public void test2(Object object) {
        for (Object other : otherObjects) {
            other.equals(object);
        }
    }

}

Equivalent bytecode is

Compiled from "TestClass.java"
public class rs.djm.TestClass {
  public rs.djm.TestClass();
    Code:
       0: aload_0
       1: invokespecial #10                 // Method java/lang/Object."<init>":()V
       4: return

  public void test1(java.lang.Object);
    Code:
       0: aload_0
       1: getfield      #18                 // Field otherObjects:[Ljava/lang/Object;
       4: dup
       5: astore        5
       7: arraylength
       8: istore        4
      10: iconst_0
      11: istore_3
      12: goto          29
      15: aload         5
      17: iload_3
      18: aaload
      19: astore_2
      20: aload_1
      21: aload_2
      22: invokevirtual #20                 // Method java/lang/Object.equals:(Ljava/lang/Object;)Z
      25: pop
      26: iinc          3, 1
      29: iload_3
      30: iload         4
      32: if_icmplt     15
      35: return

  public void test2(java.lang.Object);
    Code:
       0: aload_0
       1: getfield      #18                 // Field otherObjects:[Ljava/lang/Object;
       4: dup
       5: astore        5
       7: arraylength
       8: istore        4
      10: iconst_0
      11: istore_3
      12: goto          29
      15: aload         5
      17: iload_3
      18: aaload
      19: astore_2
      20: aload_2
      21: aload_1
      22: invokevirtual #20                 // Method java/lang/Object.equals:(Ljava/lang/Object;)Z
      25: pop
      26: iinc          3, 1
      29: iload_3
      30: iload         4
      32: if_icmplt     15
      35: return
}

The difference in bytecode are on lines 19, 20 and 21.

---

And those links you have referenced they are not about speed but about the NullPointerException and Strings in Java.