Performance and Exceptions

[Chris]

Do methods that can potentially throw an Exception (but don't) execute
any slower than methods that don't throw Exceptions?

Do code blocks enclosed in try/catch execute slower that those that aren't?

For example, does this execute slower:

for (i = 0; i < 1000000; i++) {
try {
myObject.whatever();
} catch (SomeUncheckedException e) {
// handle it here
}
}

than this?

for (i = 0; i < 1000000; i++) {
myObject.whatever();
// ignore unchecked exception
}

 

[EJP]

Do methods that can potentially throw an Exception (but don't) execute
any slower than methods that don't throw Exceptions?

Do code blocks enclosed in try/catch execute slower that those that aren't?

Last time I looked into this, the main costs of exception handling occur
when you throw & catch one. That was for fully-compiled code but offhand
I don't see why it should be too different for an interpretive system.

 

[jmcgill]

Last time I looked into this, the main costs of exception handling occur
when you throw & catch one. That was for fully-compiled code but offhand
I don't see why it should be too different for an interpretive system.

An O'Reilly benchmark, in the Java Performance Tuning book,
tests the extra cost of putting a try-catch with no exception, in a
loop, instead of around the loop.

This is not a compiler test, it's a vm test. It turns out to be pretty
hard to set up, since any decent (recent) compiler will do a good job of
optimizing your test away.

Most of the VM's tested had a 10% increase in time for having the
try-catch inside the loop, especially those running a JIT.

A much more interesting test in the same chapter, shows that a
conditional instanceof is far more efficient than trying and catching a
ClassCastException.

 

[Chris Uppal]

Do methods that can potentially throw an Exception (but don't) execute
any slower than methods that don't throw Exceptions?

To a first approximation, no. "setting up" an exception handler is (or
damn-well should be) a zero-cost operation.

However the possibility that an exception might be thrown and caught may
interfere with optimisations performed by the JITer, so it is /possible/ that a
loop without exception handling could run faster than one with.

-- chris

 

[Chris Smith]

To a first approximation, no. "setting up" an exception handler is (or
damn-well should be) a zero-cost operation.

Just to be picky, that's only true if you assume no optimization.
Exception handling does limit the possibilities for code optimizers, by
essentially inserting a lot of control flow possibilities that can
prevent the compiler from reordering certain statements in order to fill
the CPU pipelines. In particular, if you catch something like
NullPointerException that could happen at any time, then memory stores
often can't be moved very much earlier, lest they get executed when they
shouldn't and then a catch block observe the old value. I don't know
exactly how big an issue this is, but at least my Muchnick book mentions
it as being significant.