Performance and Exceptions

Thread view:

Chris - 09 Aug 2006 04:11 GMT

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
}

Reply to this Message

EJP - 09 Aug 2006 06:01 GMT

> 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.

Reply to this Message

jmcgill - 09 Aug 2006 06:52 GMT

>> Do methods that can potentially throw an Exception (but don't) execute
>> any slower than methods that don't throw Exceptions?
[quoted text clipped - 5 lines]
> 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.

Reply to this Message

Chris Uppal - 09 Aug 2006 10:38 GMT

> 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

Reply to this Message

Chris Smith - 09 Aug 2006 20:46 GMT

> 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.

Signature

Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

Reply to this Message

Performance and Exceptions

Free Magazines