2

In both Java and .Net, I've heard that using null first if (null == myObject) is more performant than using the object first if (myObject == null). While I think this is probably true, I'm not certain and would like to know from SO users. Personally, I think it reads better if the object is referenced first, but if there's any performance gain by using null first, I'll opt for that instead.

johntrepreneur
  • 4,514
  • 6
  • 39
  • 52

4 Answers4

6

They're exactly the same. If there was a difference, any compiler would make the swap as there is absolutely no functional difference.

Denys Séguret
  • 372,613
  • 87
  • 782
  • 758
5

Surprise, they compile differently in Java:

if (myObject == null);
if (null == myObject);

compiles to

 8 aload_1
 9 ifnonnull 12 (+3)
12 aconst_null
13 aload_1
14 if_acmpne 17 (+3)

(This was compiled using javac 1.6.0_24.)

Putting the object reference first results in two instructions, and putting the null first results in three instructions. On that basis, if (myObject == null) might be faster.

However, as Thorbjørn Ravn Andersen points out, when using a JIT compiler the number of bytecode instructions doesn't mean much, as the bytecode will be converted to native code before execution anyway. And even if there is a performance difference, I doubt it would be measurable.

matts
  • 6,738
  • 1
  • 33
  • 50
  • 2
    You cannot decide execution speed from the number of byte codes if your JVM uses a JIT compiler. – Thorbjørn Ravn Andersen Mar 14 '13 at 22:10
  • +1 On mentioning the bytecode. The same reason string concatenation is less efficient with the `+` operator then using a `StringBuilder`. – Bart Mar 14 '13 at 22:13
  • @ThorbjørnRavnAndersen Ah good point. I'll adjust my answer. – matts Mar 14 '13 at 22:22
  • @matts you stated "And even if there is a performance difference, I doubt it would be measurable". Wouldn't larger objects then take longer if its evaluating the whole object as opposed to small object just to see if its null? I would think it would short circuit out of checking the whole object if it knows it just needs to see if its null. – johntrepreneur Mar 14 '13 at 22:37
  • 1
    @johntrepreneur Well I'm no expert, but I don't think the size of the object makes a difference here. When used with objects, the `==` operator compares the object references, similar to pointers in other languages. It doesn't actually evaluate the object's value. Also, an object itself cannot *be* null, only a variable (which can point at an object) may be null. – matts Mar 14 '13 at 22:45
  • In C# I had the same before adding a fake istruction between the two tests. Without that fake op the bytecode emitted is optimized to reuse the null value already in the registers. – Steve Mar 14 '13 at 23:02
  • @matts ahh you're right good point (+1). I guess I'm mixing up the different languages I'm using it in. In Java, yes; in C# == is overloaded to allow an equality check although I think that's just syntactic sugar so it's probably the same as Java. However, in javascript you can use the == operator to check for equality although now I'm getting outside the scope of my original question since I didn't ask for this language, but I'm still curious as this practice can be applied there too. – johntrepreneur Mar 14 '13 at 23:08
  • @matts just to summarize, if the == operator is checking for equality like in javascript, then it will evaluate the objects content and traversing a bigger object will take more time if it doesn't know ahead of time it's just looking for null (i.e. null on left). – johntrepreneur Mar 14 '13 at 23:10
  • @johntrepreneur in Java the `==` operator isn't overloaded to compare objects' content for equality. You have to use the `equals` method for that. When used on two separate objects, `==` evaluates to `false`, even if they have equal content. For instance, `new String("test") == new String("test")` should evaluate to `false`, although `new String("test").equals(new String("test"))` will evaluate to `true`. Not sure if that answers your question – matts Mar 14 '13 at 23:42
  • @matts thanks but no that's Java 101 basics. No, my question was in reference to **Javascript** where you [can check for equality with ==](http://www.w3schools.com/js/js_comparisons.asp) and since that is the case, how does it work with bigger objects? More specifically, if the object is on the left of the conditional (in Javascript) `if (myObject == null)`, will it read the whole object first and then do the null check? as opposed to having `if (null = myObject)` knowing it just needs to know if it's null and short circuiting out of reading the object as soon as it realizes it's not null. – johntrepreneur Mar 15 '13 at 00:09
  • @johntrepreneur Ohhh, sorry I misunderstood; I have no idea about JavaScript, but I *think* `null` is a constant and I would *guess* that since many JavaScript engines these days also use a JIT, they would optimize out a full object comparison. – matts Mar 15 '13 at 03:31
2

I would expect Java to generate exactly the same bytecode for both versions (probably the ifnull bytecode), so use whichever reads better to you.

Louis Wasserman
  • 191,574
  • 25
  • 345
  • 413
2

Can't say for Java but I will be very surprised if there, it is different.
In a C# sample I write

void Main()
{
    object o = new object();

    if(null == o)
        Console.WriteLine("o is null");

    // to force a reload of the registers
    o = new object();

    if(o == null)
        Console.WriteLine("o is null");
}

the resulting IL code is 

IL_0000:  newobj      System.Object..ctor
IL_0005:  stloc.0     // o
IL_0006:  ldloc.0     // o
IL_0007:  brtrue.s    IL_0013
IL_0009:  ldstr       "o is null"
IL_000E:  call        System.Console.WriteLine
IL_0013:  newobj      System.Object..ctor
IL_0018:  stloc.0     // o
IL_0019:  ldloc.0     // o
IL_001A:  brtrue.s    IL_0026
IL_001C:  ldstr       "o is null"
IL_0021:  call        System.Console.WriteLine

NO DIFFERENCE AT ALL

Steve
  • 213,761
  • 22
  • 232
  • 286