8

I know that going into a catch block has some significance cost when executing a program, however, I was wondering if entering a try{} block also had any impact so I started looking for an answer in google with many opinions, but no benchmarking at all. Some answers I found were:

  1. Java try/catch performance, is it recommended to keep what is inside the try clause to a minimum?
  2. Try Catch Performance Java
  3. Java try catch blocks

However they didn't answer my question with facts, so I decided to try it for myself.

Here's what I did. I have a csv file with this format:

host;ip;number;date;status;email;uid;name;lastname;promo_code;

where everything after status is optional and will not even have the corresponding ; , so when parsing a validation has to be done to see if the value is there, here's where the try/catch issue came to my mind.

The current code that I inherited in my company does this:

StringTokenizer st=new StringTokenizer(line,";");  
String host = st.nextToken();
String ip = st.nextToken();
String number = st.nextToken();
String date = st.nextToken();
String status = st.nextToken();                             
String email = "";
try{
    email = st.nextToken();
}catch(NoSuchElementException e){
    email = "";
}

and it repeats what it's done for email with uid, name, lastname and promo_code.

and I changed everything to:

if(st.hasMoreTokens()){
    email = st.nextToken();
}

and in fact it performs faster. When parsing a file that doesn't have the optional columns. Here are the average times:

 --- Trying:122 milliseconds
 --- Checking:33 milliseconds

however, here's what confused me and the reason I'm asking: When running the example with values for the optional columns in all 8000 lines of the CSV, the if() version still performs better than the try/catch version, so my question is

Does really the try block does not have any performance impact on my code?

The average times for this example are:

--- Trying:105 milliseconds
--- Checking:43 milliseconds

Can somebody explain what's going on here?

Thanks a lot

Community
  • 1
  • 1
hectorg87
  • 753
  • 1
  • 7
  • 24
  • everytime checking the condition makes the program run slower. It is not a good idea to have multiple IF statements. Your company approach seems understandable. Whenever any errors are raised, you can have catch block to see what it is about. – Alpesh Prajapati Jun 11 '12 at 10:45
  • I would not second this. In his case, email is optional, so `st` having no more tokens is not an exceptional case, but may happen very often. Using an exception here is no good style. – gexicide Jun 11 '12 at 10:47
  • Not only will happen very often, is the default behavior. We will only get the optional fields in many little occasions – hectorg87 Jun 11 '12 at 10:49
  • I don't know if this might help somebody, but I'm running the "benchmark" in Java jdk_linux_x86_1.6.0.13 on my Ubuntu 10.04 with Intel Pentium Dual-Core 2.70 Ghz – hectorg87 Jun 11 '12 at 11:08
  • @AlpeshPrajapati I found this other two post which discuss the use of try/catch as a control flow mechanisms. They are nice so I though of sharing them [here](http://stackoverflow.com/questions/2409179/is-it-better-to-use-try-catch-instead-of-multiple-if-statements) and [here](http://stackoverflow.com/questions/3490770/what-is-faster-try-catch-or-if-else-in-java-wrt-performance) – hectorg87 Jun 11 '12 at 13:24

1 Answers1

12

Yes, try (in Java) does not have any performance impact. The compiler generates no VM statements for a try block. It simply records the program counters between which the try block is active and attaches this information to the method in the class file. Then, when an exception is thrown, the VM unwinds the stack and checks at each frame whether the program counter in that frame is in a relevant try block. This (together with building the stack trace) is quite costly, so catching is expensive. However, trying is free :).

Still, it is not good practice to use exceptions for regular control flow.

The reason why your code performs faster is probably that catching is so extremely costly that it outweights the time saved by replacing the check by a simple try.

Try catch can be faster in code where the catch is triggered not very often, e.g., if you go into the try 10000 times but only catch once, the try method would be faster than the if-check. Still, this is no good style and your way of explicitly checking for more tokens is to be preferred.

gexicide
  • 38,535
  • 21
  • 92
  • 152
  • Thanks, I really understand this, however the code I tried says otherwise, it performs likes the try{} it's giving it some overhead at runtime, and that's what my question is about.I can paste the test code somewhere so you can try it and see for yourself. – hectorg87 Jun 11 '12 at 10:47
  • okay, I see. Well, the problem could be that the try is harder to optimize. However, the performance impact is neglectable anyway. As a rule of thumb, you should never consider exchanging if with try/catch for optimization reasons. Just use try/catch for exceptional behaviour and if for regular control flow. Everything else is a hack. – gexicide Jun 11 '12 at 10:51
  • The times I gave in my question are 1) when entering the catch block ALWAYS (8000 times * 5 columns) and 2) not entering the catch block never because the optional columns are always there – hectorg87 Jun 11 '12 at 10:51
  • This try/catch construct is very often used in real time environments where the execution time is very important and you don't expect many errors. – boskop Jun 11 '12 at 10:53
  • if you already say 'expect many errors' then your are talking about exceptional situations. In those, try/catch is fine anyway. – gexicide Jun 11 '12 at 10:53
  • I agree with you, one should NEVER use exceptions for regular control flow. Let's give the question some more time to see if somebody with deep java internals can give an accurate answer on why is it performing faster with the if when never entering the catch blocks – hectorg87 Jun 11 '12 at 10:53
  • The problem is that the answer is VM dependant. My answer states what the specification says about try/catch. Anything else is implementation dependant. So, it might be the case that if performs faster on your VM because it can optimize if better than try/catch. On other VMs or processors, the opposite might be the case. – gexicide Jun 11 '12 at 10:55
  • I don't know if this might help somebody, but I'm running the "benchmark" in Java jdk_linux_x86_1.6.0.13 on my Ubuntu 10.04 with Intel Pentium Dual-Core 2.70 Ghz – hectorg87 Jun 11 '12 at 11:07