Considering long time performance costs of "if" statements and exceptions

I've always thought that using a "if" is way better (in performance terms) than catching an exception. For example, doing this:

User u = Users.getUser("Michael Jordan");
if(u!=null)
   System.out.println(u.getAge());

vs.

User u = Users.getUser("Michael Jordan");
try{
   System.out.println(u.getAge());
}catch(Exception e){
   //Do something with the exception
}

If we benchmark this, it's 开发者_Python百科quite obvious that the first snippet is faster than the second one. That's what i've always thought. But, yesterday, a guy told me something like this:

Have you ever considered what happens in thousands of executions of your programs? Every time your execution goes through your "if" you've a little (real little, but still something) performance cost. With exceptions it doesn't happens. Becouse it could never arise.

To make it clear: thousands of times executing an "if" vs one exception catch.

I think it has sense, but don't have any proof.

Can you help me?

Thanks!!

No. Not once the JIT kicks in. Tell him to read up on trace caches.

A dynamic trace ("trace path") contains only instructions whose results are actually used, and eliminates instructions following taken branches (since they are not executed); a dynamic trace can be a concatenation of multiple basic blocks. This allows the instruction fetch unit of a processor to fetch several basic blocks, without having to worry about branches in the execution flow.

Basically, if the same branches are taken every time through a loop body, then that body ends up as a single trace in the trace cache. The processor will not incur the cost of fetching the extra branch instructions (unless that pushes the basic block over the limit of what can be stored in the trace cache, unlikely) and does not have to wait for the result of the test before starting to execute following instructions.

Do not ever, EVER, sacrifice your code quality for performance until you've proven beyond a reasonable doubt it's actually called for. I highly doubt that the performance of if() statement will ever become the bottleneck of you program. If it does, you should re-write it in C. In Java land, 99% of the time the bottleneck is the I/O - disk and/or network.

Except for maybe machine exceptions, any exception you've caught has been preceded by some kind of if conditional. Even a NullPointerException was thrown following a if(something == null) down in the JVM. Don't worry about the performance of an if statement. Don't worry about the performance of try/catch either since presumably an error should occur much less frequently than successful execution. I don't think you need to optimize how fast your errors are thrown. :-)

You have no proof because you have no case. It is certainly an interesting abstract question if you have a piece of code that was a bottleneck that you could eliminate an if for because one side of the condition was very rare, then it might mean something. But in the abstract, doing that with exceptions is making code harder to read and maintain, so it should not be done without a real world problem in front of you. In the real world, it may throw the exception 50% of the time. You don't know until you have a real-world scenario.