«

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

On Wed, 13 Jul 2005 08:21:12 -0700, kk_oop wrote:

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

wrote:
> 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] = i;

try {
for (int i = 0; ; ++i)
array[i] = 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.

--

wrote:

> 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

Eric Sosman wrote:

> 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

Paul Bilnoski wrote:
> wrote:
>
>> 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?

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

Robert Klemme wrote:
> Paul Bilnoski wrote:
>
>> wrote:
>>
>>
>>>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?
>
>
> 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
>

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

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

--
Regards,
Casey

Andrea Desole wrote:
>
>
> Eric Sosman wrote:
>
>> 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

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

Cantankerous Old Git wrote:
> Andrea Desole wrote:
>
>>
>>Eric Sosman wrote:
>>
>>
>>> 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
>
>
> 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.

--