-3

Which is the best way to check varName of null and to call method name methodName2?

void methodName(String varName) {
    if (varName == null) {
        return;
    }
    methodName2();
}
//or 
void methodName(String varName) {
    if (varName != null) {
        methodName2();
    }
}
void methodName2() {
    // do the stuff
}
Sagar Zala
  • 4,854
  • 9
  • 34
  • 62
100rbh
  • 763
  • 1
  • 7
  • 10
  • 1
    Besides that it is opinion based, you would do the first construct if you had many different exit conditions. – Murat Karagöz Oct 18 '18 at 10:34
  • 1
    Possible duplicate of [Check whether a string is not null and not empty](https://stackoverflow.com/questions/3598770/check-whether-a-string-is-not-null-and-not-empty) – Vivek Mishra Oct 18 '18 at 10:35

3 Answers3

2

Both approaches require a single check on the string varName to see whether or not it be null. So, from a performance point of view, both should be almost the same. That being said, I personally prefer the first version:

void methodName(String varName) {
    if (varName == null) {
        return;
    }

    methodName2();
}

I prefer this because null is explicitly handled as a case where methodName() just returns without doing anything else. In your second version, the final behavior is the same, but it is less obvious from the code. Also, the second version leaves a potential maintenance problem. Suppose someone inherits your code and needs to add functionality:

void methodName(String varName) {
    if (varName != null) {
        methodName2();
    }

    // let's make the method do something else
}

Since the null input case has been left free to run amok, there is a chance that it might enter into some code which you never intend for it to see.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
1

There is only one way to be sure. Benchmark it using jmh.

(My gut feeling is that the JIT compiler will be able to produce native code for for the two versions that is identical in performance. It should not be that hard to do that ...)

But there is a bigger lesson here. In a real world program, a (hypothetical!!) small difference in performance between these two constructs is unlikely to make a significant difference to the overall performance of the application as a whole. Indeed, if you are not careful, you are liable to waste lots of your time optimizing things that don't matter. Unless you have studied the JIT compiler and the optimizations it performs ... in depth ... your intuition about what is going to matter is likely to be flawed.

Furthermore, you are liable to find that the "micro" performance depends on details that are typically outside of your control:

  • JRE minor versions
  • differences in behavior of different chipsets due to pipeline differences, different L1 & L2 cache sizes, etcetera
  • different physical memory and heap sizes

Your micro-optimizations for one JRE, chipset, etc may actually make things worse on a newer JRE, different chipset, etcetera/

The best strategy is leave the "micro" optimization to the JIT compiler.

And if you need to hand optimize:

  1. Create a realistic benchmark for the entire application (or library).
  2. Set some quantifiable performance goals.
  3. Get the software to work.
  4. Benchmark it. If it meets the goals, STOP!
  5. Profile it to find the hotspots.
  6. Pick a fresh hotspot to optimize. If there are none left where the percentage time spent is large enough to make a difference, STOP!
  7. Hand optimize the hotspot.
  8. Benchmark / profile again. Did that improve things? If no, BACK OUT the optimization.
  9. Repeat.
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

Strictly, the answer depends on the JRE you're running in. The second version is easier for the JIT to prune completely, if it can tell your variable either always is (or isn't ever) null. A better JRE will be able to do the same optimisation anyway.

However I'd argue you're asking the wrong question. This level of micro-optimisation is almost never useful. There are essentially no circumstances where the performance improvements of one over the other outweigh the readability concerns. You should be asking yourself which communicates intent more clearly, and which is less likely to cause future problem when you revisit the code in a year's time.

Clive Evans
  • 658
  • 8
  • 12