Java Exceptions cause performance hit?

[kk_oop]

Hi. I wanted to use exceptions to handle error conditions in my code.
I think doing that is useful, as it helps to separate "go" paths from
error paths. However, a coding guideline has been presented that says
"Use conventional error-handling techniques rather than exception
handling for straightforward local error processing in which a program
is easily able to deal with its own errors."

By "conventional error-handling," I believe they mean returning an
error code, or just handling the error without going to a catch block.


When I said that I'd prefer throwing and catching exceptions--and that,
in fact, exceptions is the "conventional error-handling technique" in
Java, I was told that since we have a real-time system, we can't afford
the performance hit caused by using exceptions.

Do exception blocks cause big performance hits? If so, what causes the
hit? Or is the person just misinformed?

Thanks for any info,

Ken

 

[Steve Wampler]

Do exception blocks cause big performance hits? If so, what causes the
hit? Or is the person just misinformed?

I don't know how Java implements exception handling, but having
done it in another language I would say that the only significant
performance hit *should* be the construction of the stack trace
(and even there one could argue about the definition of
'significant'...). Plus, the ability of an thrown exception to
perform a 'deep return' may help mitigate that cost.

Personally, I think the benefit outweighs the cost, but I could
understand someone (especially in a RT system) possibly wanting
to cut that cost out - particularly if the stack trace could be
turned on/off dynamically).

One wonders, however, what Java version you're using in a
real-time system...

 

[Eric Sosman]

Hi. I wanted to use exceptions to handle error conditions in my code.
I think doing that is useful, as it helps to separate "go" paths from
error paths. However, a coding guideline has been presented that says
"Use conventional error-handling techniques rather than exception
handling for straightforward local error processing in which a program
is easily able to deal with its own errors."

By "conventional error-handling," I believe they mean returning an
error code, or just handling the error without going to a catch block.


When I said that I'd prefer throwing and catching exceptions--and that,
in fact, exceptions is the "conventional error-handling technique" in
Java, I was told that since we have a real-time system, we can't afford
the performance hit caused by using exceptions.

Do exception blocks cause big performance hits? If so, what causes the
hit? Or is the person just misinformed?

Creating, throwing, catching, and eventually garbage-
collecting a Throwable object is certainly a lot more work
than a simple `if'. You can measure it for yourself by
comparing the time required for two different ways of
filling an array:

for (int i = 0; i < array.length; ++i)
array = i;

try {
for (int i = 0; ; ++i)
array = i;
} catch (ArrayIndexOutOfBoundsException ex) {}

(This is pretty much the same experiment Joshua Bloch shows
in "Effective Java.") On the machine I'm using at the moment,
the exception-based approach takes 15.5 times as long as the
straightforward loop to fill a 100-element array; that is, one
exception takes longer than 1500 limit tests. Your machine
may give different timings; try it and see.

Note that the guidance you've been given does not forbid
the use of exceptions; it only forbids them for "straightforward
local error processing." I suggest you go back to the folks
who wrote the guidelines and ask what "straightforward" means;
it will probably turn out to be less burdensome than you seem
to fear.

 

[Paul Bilnoski]

When I said that I'd prefer throwing and catching exceptions--and that,
in fact, exceptions is the "conventional error-handling technique" in
Java, I was told that since we have a real-time system, we can't afford
the performance hit caused by using exceptions.

Do exception blocks cause big performance hits? If so, what causes the
hit? Or is the person just misinformed?

The problem with exceptions in hard real-time systems is that it
introduces more invariants with respect to the expense of execution. It
becomes more difficult to make guarantees about time and memory used, so
I think that may be why it is preferred against when you can use
something conventional in simpler cases.
There may be some threshold of complexity where you opt for an exception
over checking flags or error codes.
There is a similar problem with garbage collection and making running
time more predictable that RT implementations account for.
--Paul

 

[Andrea Desole]

Note that the guidance you've been given does not forbid
the use of exceptions; it only forbids them for "straightforward
local error processing." I suggest you go back to the folks
who wrote the guidelines and ask what "straightforward" means;
it will probably turn out to be less burdensome than you seem
to fear.

Good point.
I was just wondering why worry about performance if an exception is for,
well, exceptional cases. If an exception is being thrown so often to
have a performance impact, either you have a problem with your code or
you have a problem with your system.
Maybe that person just wants to prevent exception abuse

 

[Robert Klemme]

A thrown exception causes the hit. IMHO the penalty in the normal case
(no exception thrown) is neglectible.

The problem with exceptions in hard real-time systems is that it
introduces more invariants with respect to the expense of execution.
It becomes more difficult to make guarantees about time and memory
used, so I think that may be why it is preferred against when you can
use something conventional in simpler cases.
There may be some threshold of complexity where you opt for an
exception over checking flags or error codes.
There is a similar problem with garbage collection and making running
time more predictable that RT implementations account for.

As far as I understand the term "real time system" I wonder why someone
uses Java in the first place. There is no such thing as guaranteed
response times etc. So maybe the OP is dealing with a soft real time
system.

http://en.wikipedia.org/wiki/Real-time_system

Regards

robert

 

[Paul Bilnoski]

A thrown exception causes the hit. IMHO the penalty in the normal case
(no exception thrown) is neglectible.




As far as I understand the term "real time system" I wonder why someone
uses Java in the first place. There is no such thing as guaranteed
response times etc. So maybe the OP is dealing with a soft real time
system.

http://en.wikipedia.org/wiki/Real-time_system

Regards

robert

I used Java for a few real-time system programming projects in college.
We had a RT Linux kernel and the distributor also provided an RT Java VM
implementation though it was not the full language (no 1.4 NIO, no Swing).
There was also some extra functionality for the GC system to make it
handle in a more predictable way.

But to answer your point of "why use Java": because it is more
comfortable to program multithreaded applications than with some C++
threading libraries, among other things.
--Paul

 

[Casey Hawthorne]

Exceptions have performance penalties when thrown, only minor when not
thrown!
Depending upon how you define "minor"!

The challenge with exceptions is maintaining global state, like:
- cursor state
- timing state in real-time systems

 

[Cantankerous Old Git]

Good point.
I was just wondering why worry about performance if an exception is for,
well, exceptional cases. If an exception is being thrown so often to
have a performance impact, either you have a problem with your code or
you have a problem with your system.
Maybe that person just wants to prevent exception abuse

I haven't done any testing, so I speak in ignorance, but could it
be that setting up the try/catch block is expensive? This will
have to happen whether an Exception is actually thrown or not,
and will therefore affect error-free performance too.

The Cog

 

[Eric Sosman]

I haven't done any testing, so I speak in ignorance, but could it
be that setting up the try/catch block is expensive? This will
have to happen whether an Exception is actually thrown or not,
and will therefore affect error-free performance too.

Look at the bytecode, and you'll see that it's very
cheap. The cost amounts to one unconditional jump at the
end of the `try' clause to skip over the `catch' clause(s).
It's possible that the JIT compiler might reorganize the
compiled code to eliminate even that much overhead.

 

[Joan]

Hi. I wanted to use exceptions to handle error conditions in my code.
I think doing that is useful, as it helps to separate "go" paths from
error paths. However, a coding guideline has been presented that says
"Use conventional error-handling techniques rather than exception
handling for straightforward local error processing in which a program
is easily able to deal with its own errors."

The key is "easily able to deal with its own errors." If it ain't easy, use
toss/catch (if you want.)

 

[John Currier]

Eric, your "performance comparison" is slightly skewed. The
performance characteristics of the two approaches is highly dependent
on the number of iterations and the cost of checking for the
terminating condition. In your comparison the number of iterations
(100) times the cost of checking (i < array.length) is extremely small
compared to the cost of creating and throwing the exception. There are
many scenarios where the opposite is true.

John
http://schemaspy.sourceforge.net

 

[Andrea Desole]

Look at the bytecode, and you'll see that it's very
cheap. The cost amounts to one unconditional jump at the
end of the `try' clause to skip over the `catch' clause(s).
It's possible that the JIT compiler might reorganize the
compiled code to eliminate even that much overhead.

I can imagine.
I think that the impact on the performance is basically due to two factors:

1) exception construction (specially the stack, I believe)
2) search for an appropriate exception handler (you have to go through
the entire stack until you find one)

 

[Thomas Schodt]

I think that the impact on the performance is basically due to two factors:

1) exception construction (specially the stack, I believe)

Yes, construction of the stack trace is rather expensive.

<http://java.sun.com/j2se/1.5.0/relnotes.html#hotspot>

The compiler in the server VM now provides correct stack backtraces for
all "cold" built-in exceptions. For performance purposes, when such an
exception is thrown a few times, the method may be recompiled. After
recompilation, the compiler may choose a faster tactic using
preallocated exceptions that do not provide a stack trace. To disable
completely the use of preallocated exceptions, use this new flag:
-XX:-OmitStackTraceInFastThrow.

2) search for an appropriate exception handler
(you have to go through the entire stack until you find one)

Once the exception has been constructed
unrolling of the stack (and executing finally blocks)
should perform not much different from
unrolling of the stack due to return statements.

 

[Andrea Desole]

Once the exception has been constructed
unrolling of the stack (and executing finally blocks)
should perform not much different from
unrolling of the stack due to return statements.

Well, what I mean is that, while you are unwinding the stack and
executing finally blocks, you also have to check, at every stack frame,
if there is a catch block able to handle the exception.
But maybe you are right anyway: it shouldn't be a big difference.

 

[Ken]

Yes, construction of the stack trace is rather expensive.

Is this price paid at run time only when an exception is actually
thrown? Or does simply having a try/catch block or a throw statement
in the java code cause this to happen at run time even when an
exception is not thrown?

Thanks!

Ken

 

[Andrea Desole]

Is this price paid at run time only when an exception is actually
thrown? Or does simply having a try/catch block or a throw statement
in the java code cause this to happen at run time even when an
exception is not thrown?

when the exception is not thrown is not constructed, so there is no problem

 

[Steve Wampler]

Well, what I mean is that, while you are unwinding the stack and
executing finally blocks, you also have to check, at every stack frame,
if there is a catch block able to handle the exception.
But maybe you are right anyway: it shouldn't be a big difference.

Gaak. I hope the JVM doesn't unroll the stack. It should be
using a simple (internal) hash map to 'jump' directly to the
correct catch clause. Yes, that adds a small bit to each
try block to adjust the hash map, but most of the work
for it can be done at translation time.

 

[Steve Wampler]

...I hope the JVM doesn't unroll the stack.

Oops, I meant "unwind", not unroll. Of course the stack is
rolled back to some previous point, but shouldn't be an
unwinding process.

 

[Steve Wampler]

Gaak. I hope the JVM doesn't unroll the stack.

Sigh. Ignore me. I forgot about those finally blocks,
which force some unwinding...