Null check vs try/catch when 99% of the time object is not null

Question

Normally I prefer null check. But in current scenario I know that most of the time my if condition will pass and there are few legitimate scenario where object may be null.

Also, load is huge (about 5 million calls / hour)

Now I trying to find which way is better from performance perspective. Already checked try/catch vs null check in java but my case is unique.

Also checked Which is faster, try catch or if-else in java (WRT performance) but both this one and above ones are in generic context where knowledge of pass/fail ratio is not available.

public void process(Job job) {
    //... some code which processes job

    SubJob subJob = job.getSubJob();
    if(subJob != null) {  // 99% of the time this will pass
        //.. do something
    }               
}

try/catch version

public void process(Job job) {
    //... some code which processes job

    SubJob subJob = job.getSubJob();
    try {
        //.. do something  
    }catch(NullPointerException e) { //This may occure only 1% of the time. 
        //...   
    }               
}

Update:

Winner is null check. In Try/catch, internally JVM will do null check and throw NPE anyway and on top of that exception handling in JVM (creation of stack etc) will be overhead. Also as per another answer, modern CPUs are intelligent enough to handle these scenario with good prediction which in my unique case will always work in favor.

I also wrote program (posted below under my name) and results are clearly indicating that null check is way better on my AMD processor.

Thank you folks for guiding me.

Answer 1

TL;DR: If you don't do the null check in your code, the runtime will insert one for you anyway. Null checks almost always have zero cost.

---

You need to view this problem from the perspective of HotSpot or an optimizing JIT compiler:

When you call a method on an object variable

someObject.callMethod()

then the runtime needs to throw a NPE if the variable is null (Pseudo ASM):

check someObject ref not null else throw NPE
invoke 'callMethod' on 'someObject' 

Now sometimes the runtime can be sure that a variable is not null. This analysis is called null check elimination.

-- no need: check someObject ref not null else throw NPE
invoke 'callMethod' on 'someObject' 

The clue is that your check in the Java source code

if (someObject != null)

is good enough to prove to the runtime that the variable is not null.

The rationale:

Always prefer a null check over catching a NPE. If you don't do the null check then the runtime will insert it for you.

Answer 2

Go with the null checks, the processor will pipeline it and should always "ignore" the if and go on through to the statement.

Similar, talks about pipelining: Why is it faster to process a sorted array than an unsorted array?