CODEWITHSUNDEEP
javaperformance
Kevin K
Kevin K

Reputation: 9584

Does equality test order affect performance in Java?

I commonly find myself writing code like this:

private List<Foo> fooList = new ArrayList<Foo>();

public Foo findFoo(FooAttr attr) {
    for(Foo foo : fooList) {
        if (foo.getAttr().equals(attr)) {
            return foo;
        }
    }
}

However, assuming I properly guard against null input, I could also express the loop like this:

for(Foo foo : fooList) {
    if (attr.equals(foo.getAttr()) {
        return foo;
    }
}

I'm wondering if one of the above forms has a performance advantage over the other. I'm well aware of the dangers of premature optimization, but in this case, I think the code is equally legible either way, so I'm looking for a reason to prefer one form over another, so I can build my coding habits to favor that form. I think given a large enough list, even a small performance advantage could amount to a significant amount of time.

In particular, I'm wondering if the second form might be more performant because the equals() method is called repeatedly on the same object, instead of different objects? Maybe branch prediction is a factor?

Upvotes: 0

Views: 144

Answers (6)

Peter Lawrey
Peter Lawrey

Reputation: 533700

The only thing which does affect performance is code which does nothing.

In some cases you have code which is much the same or the difference is so small it just doesn't matter. This is the case here.

Where its is useful to swap the .equals() around is when you have a known value which cannot be null (This doesn't appear to be the cases here) of the type you are using is known.

e.g.

Object o = (Integer) 123;
String s = "Hello";

o.equals(s); // the type of equals is unknown and a virtual table look might be required
s.equals(o); // the type of equals is known and the class is final.

The difference is so small I wouldn't worry about it.

DEVENTER (n) A decision that's very hard to make because so little depends on it, such as which way to walk around a park

-- The Deeper Meaning of Liff by Douglas Adams and John Lloyd.

Upvotes: 1

Matt
Matt

Reputation: 11805

The performance should be the same, but in terms of safety, it's usually best to have the left operand be something that you are sure is not null, and have your equals method deal with null values.

Take for instance:

String s1 = null;
s1.equals("abc");
"abc".equals(s1);

The two calls to equals are not equivalent as one would issue a NullPointerException (the first one), and the other would return false.

The latter form is generally preferred for comparing with string constants for exactly this reason.

Upvotes: 0

Martijn Courteaux
Martijn Courteaux

Reputation: 68887

This depends on the implementation of the equals methods. In this situation I assume that both objects are instances of the same class. So that would mean that the methods are equal. This makes no performance difference.

Upvotes: 2

Guillaume Polet
Guillaume Polet

Reputation: 47607

If both objects are of the same type, then they should perform the same. If not, then you can't really know in advance what's going to happen, but usually it will be stopped quite quickly (with an instanceof or something else).

For myself, I usually start the method with a non-null check on the given parameter and I then use the attr.equals(foo.getAttr()) since I don't have to check for null in the loop. Just a question of preference I guess.

Upvotes: 1

schmmd
schmmd

Reputation: 19478

I think that considering branch prediction is worrying about efficiency at too low of a level. However, I find the second example of your code more readable because you put the consistent object first. Similarly, if you were comparing this to some other object that, I would put the this first.

Of course, equals is defined by the programmer so it could be asymmetric. You should make equals an equivalence relation so this shouldn't be the case. Even if you have an equivalence relation, the order could matter. Suppose that attr is a superclass of the various foo.getAttr and the first test of your equals method checks if the other object is an instance of the same class. Then attr.equals(foo.getAttr()) will pass the first check but foo.getAttr().equals(attr) will fail the first check.

However, worrying about efficiency at this level seldom has benefits.

Upvotes: 2

dty
dty

Reputation: 18998

I would offer 2 pieces of advice here:

  1. Measure it
  2. If nothing else points you in any given direction, prefer the form which makes most sense and sounds most natural when you say it out loud (or in your head!)

Upvotes: 4

Related Questions