- Exceptions in Java
- Using Exceptions To Write Elegant Code
- The Problem: Using Exceptions for Control-Flow
- Performance Tests of the Two Code Samples
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Performance Tests of the Two Code Samples
To understand the effects of using exceptions instead of conditionals, we ran a test using the two examples, countCharsWithExcep in Listing 4 and countCharsNoExcep in Listing 5. The two methods were called the same number of times. To ensure that the methods got compiled, we called them 100 times; 1,000 times; 5,000 times, and 10,000 times. The test was done on a laptop running Windows XP using several versions of commercial JVMs from three vendors. The results are presented in the following table. The time taken for countCharsNoExcep was less than 1 millisecond (ms) for all the runs. But for countCharsWithExcep, the times ranged from 10 ms at 1,000 iterations to 260 ms at 10,000 iterations. The actual time varied for each JVM; we believe that with sufficient tuning applied, some of these numbers could be reduced and maybe even all fall to the same level. But it was very clear that the case with exceptions showed at least an order of magnitude extra cost above the one without exceptions.
|
JVM |
100 Iterations |
1,000 Iterations |
5,000 Iterations |
10,000 Iterations |
||||
|
No Ex |
340 Ex |
No Ex |
3,400 Ex |
No Ex |
17,000 Ex |
No Ex |
34,000 Ex |
|
|
JVM 1 |
<1 ms |
10 ms |
<1 ms |
30 ms |
<1 ms |
140 ms |
<1 ms |
261 ms |
|
JVM 2 |
<1 ms |
<1 ms |
<1 ms |
80 ms |
<1 ms |
170 ms |
<1 ms |
260 ms |
|
JVM 3 |
<1 ms |
10 ms |
<1 ms |
70 ms |
<1 ms |
190 ms |
<1 ms |
311 ms |
|
JVM 4 |
<1 ms |
<1 ms |
<1 ms |
10 ms |
<1 ms |
70 ms |
<1 ms |
140 ms |
|
JVM 5 |
<1 ms |
<1 ms |
<1 ms |
10 ms |
<1 ms |
30 ms |
<1 ms |
40 ms |
This is a micro-benchmark, and therefore it's not easy to extrapolate the results to a real application. But the actual results could vary drastically based on the application profile. For example, this method could be in a critical region where a slowdown could ripple through a lot of other components that are waiting for a module to finish. Because Java is used extensively in distributed computing, multiple systems could be affected, as we found in some commercial systems. It could also lead to different timing windows on different JVMs, and cause unexpected behavior when you move the application from one system to another.