GeeCON Prague 2014*
The moose likes Performance and the fly likes Performance on handling exceptions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Performance
Bookmark "Performance on handling exceptions" Watch "Performance on handling exceptions" New topic
Author

Performance on handling exceptions

Gayan Keppetipola
Greenhorn

Joined: Nov 07, 2005
Posts: 5
Hi All,

I need to know if checking for an exception and processing it or handling an exception when it occurs would provide better performance. For example assume that I have to print the content in a String List one after another. The possibility of a null value been in the list is one in a million. If so could you please let me know which of the following code segments would provide the optimal performance.

Option A

private void printList(List<String> listString){
for (String string : listString) {
if(string !=null){
System.out.println(string.toString());
}else
System.out.println("Element is null");
}
}


Option B

private void printList(List<String> listString){
for (String string : listString) {
try{
System.out.println(string.toString());
}catch(NullPointerException e){
System.out.println("Element is null");
}
}

Thanks in advance,
Gayan
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16101
    
  21

Exceptions used to be considered pretty heavyweight. I'm sure a lot of streamling has been done, but it's still a fair amount of work to construct an exception object, fill it in with the appropriate data and context (stack trace), and bubble it up through the stack frames until someone catches it.

In constrast, a simple test for "null" can be as little as 1 machine instruction. Much, much less work. And in order to throw the NullPointerException, something has to make that test anyway, so the exception generating and handling is pure overhead. Not to mention the work spend getting down to the point where the exception is thrown that could have been bypassed by that one simple test.


Customer surveys are for companies who didn't pay proper attention to begin with.
xsunil kumar
Ranch Hand

Joined: Dec 14, 2009
Posts: 133
As per performace issue, Option A is better.
Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
xsunil kumar wrote:As per performace issue, Option A is better.


I was expecting the same... until I run a test:



My results:

testLoopWithoutTryCatchBlock : 9.733s
testLoopWithTryCatchBlock: 7.054s
testLoopWithTryFinallyBlock: 12.633s
testLoopWithTryCatchFinallyBlock: 8.730s

How do you explain that?

Thanks.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3016
    
  10
Stephane, what is it you're trying to test, anyway? The discussion assumed that there would be a null in the list one time in a million - which would lead to a NullPointerException, a relatively slow, cumbersome event. I don't see anything in your test that actually causes an exception to be thrown, ever. So it doesn't really apply to the discussion so far.

The main reason for differences in the times you see is that the first and third tests execute total++ three times in each loop iteration, while the second and fourth execute total++ twice per iteration. So the second and fourth tests are shorter, because they do less work. I don't think this tells us anything interesting, however.
Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
Mike Simmons wrote:Stephane, what is it you're trying to test, anyway? The discussion assumed that there would be a null in the list one time in a million - which would lead to a NullPointerException, a relatively slow, cumbersome event. I don't see anything in your test that actually causes an exception to be thrown, ever. So it doesn't really apply to the discussion so far.

The main reason for differences in the times you see is that the first and third tests execute total++ three times in each loop iteration, while the second and fourth execute total++ twice per iteration. So the second and fourth tests are shorter, because they do less work. I don't think this tells us anything interesting, however.


Hi,

Well... let say i make half of the job by posting my comment... and expected it will be enough.
I looks it is not the case.
What we try to demonstrate is that try catch is faster that if not null...


I finished the code to show you that solution B is beter that solution A... at least on my PC.




Results:
testLoopWithoutTryCatchBlock: 9.767s
testLoopWithTryCatchBlock: 4.585s
testLoopWithTryCatchFinallyBlock: 8.335s

I have my own idea why it is faster with testLoopWithTryCatchBlock but I would like to have a debate on that.

I tried with java 6 and java 7.
With almost the same result.

Regards,

Stephane Clinckart
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Stephane Clinckart wrote:
Results:
testLoopWithoutTryCatchBlock: 9.767s
testLoopWithTryCatchBlock: 4.585s
testLoopWithTryCatchFinallyBlock: 8.335s

I have my own idea why it is faster with testLoopWithTryCatchBlock but I would like to have a debate on that.


The simplest explanation is that testLoopWithoutTryCatchBlock compares each element to null and testLoopWithTryCatchBlock doesn't. It does more work. Therefore it takes longer.
Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
Paul Clapham wrote:
Stephane Clinckart wrote:
Results:
testLoopWithoutTryCatchBlock: 9.767s
testLoopWithTryCatchBlock: 4.585s
testLoopWithTryCatchFinallyBlock: 8.335s

I have my own idea why it is faster with testLoopWithTryCatchBlock but I would like to have a debate on that.


The simplest explanation is that testLoopWithoutTryCatchBlock compares each element to null and testLoopWithTryCatchBlock doesn't. It does more work. Therefore it takes longer.


Maybe I'm wrong... but how do you explain the result of the first test?

My results:

testLoopWithoutTryCatchBlock : 9.733s
testLoopWithTryCatchBlock: 7.054s
testLoopWithTryFinallyBlock: 12.633s
testLoopWithTryCatchFinallyBlock: 8.730s

uh?

Regards
Peter Taucher
Ranch Hand

Joined: Nov 18, 2006
Posts: 174
Stephane, I tested your code...

// edit
OK, forget what I said. Do all your tests run without errors, or did you expect some OutOfMemoryError too? ; - )


Censorship is the younger of two shameful sisters, the older one bears the name inquisition.
-- Johann Nepomuk Nestroy
Peter Taucher
Ranch Hand

Joined: Nov 18, 2006
Posts: 174
So i ran your tests with 3 million list entries (+ 3 null values) and wiht a third 'listTestC' for the third test. I ran the tests in various order. Here are my results:
IfNull ... 1,732s; 1,692s; 1,770s; 1,392s; 1,441s; 1,468s ... MAX: 1,770s ... MIN: 1,392s ... AVG: 1,583s
CatchBlock ... 1,484s; 1,476s; 1,645s; 1,477s; 1,506s; 1,537s ... MAX: 1,645s ... MIN: 1,476s ... AVG: 1,521s
CatchFinally ... 1,308s; 1,367s; 1,461s; 1,696s; 1,693s; 1,742s ... MAX: 1,742s ... MIN: 1,308s ... AVG: 1,545s

So in the end it varies much, but the average values of the six runs are very close. I doubt the significance of these tests.
Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
Peter Taucher wrote:So i ran your tests with 3 million list entries (+ 3 null values) and wiht a third 'listTestC' for the third test. I ran the tests in various order. Here are my results:
IfNull ... 1,732s; 1,692s; 1,770s; 1,392s; 1,441s; 1,468s ... MAX: 1,770s ... MIN: 1,392s ... AVG: 1,583s
CatchBlock ... 1,484s; 1,476s; 1,645s; 1,477s; 1,506s; 1,537s ... MAX: 1,645s ... MIN: 1,476s ... AVG: 1,521s
CatchFinally ... 1,308s; 1,367s; 1,461s; 1,696s; 1,693s; 1,742s ... MAX: 1,742s ... MIN: 1,308s ... AVG: 1,545s

So in the end it varies much, but the average values of the six runs are very close. I doubt the significance of these tests.


Hi,

I will try again...

I guess you used javamon for calculating the min, max, average ?

Thanks anyway for the info.

Stephane
 
 
subject: Performance on handling exceptions