C++ 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
C++, 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


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Artie Gold]

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 word here is *local*. Throwing an exception is essentially a
non-local `go to' that does the appropriate bookkeeping -- at the cost
of setting up that bookkeeping.

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

When I said that I'd prefer throwing and catching exceptions--and that,
in fact, exceptions is the "conventional error-handling technique" in
C++, 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 cost is (the compiler) setting up the bookkeeping information
necessary to make the non-local jump (in order call all necessary
destructors for any locally created objects). When an error can be dealt
with locally (i.e. there's no need to explicitly propagate the error as
deep call stack unwinds) it is worth doing so. If, on the other hand,
the call stack *is* deep, the use of exceptions (naturally, in
*exceptional* situations), while having a cost, makes the code
conceptually much clearer. As with anything else, it's a trade off.

HTH,
--ag

[c.l.c.m elided]

 

[E. Robert Tisdale]

I want 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."

That's vague but possibly sound advice.

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

You had better ask for some clarification on this.

Exceptions (what you call errors) should be handled
at the point where they are first detected if possible.
If they can't be completely handled
in the function where they are first detected,
you *must* create an exception object
which contains all of the information required
to handle the exception in the calling program
and return or throw the exception object.
In some cases, an error code may be sufficient
to contain all of the information
required to handle the exception.
If not, you may need a more complicated exception object.

When I said that I'd prefer throwing and catching exceptions and that,
in fact, exceptions [are] the "conventional error-handling technique" in C++,
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?

Again, you should ask for clarification.
Exceptions do *not* affect performance
unless an exception is encountered
and then they are probably just about as efficient
as any so-called conventional error-handling technique.
The problem with real-time programming is that
you *must* know how long it takes to execute your code.
If any of your exception (error) handling is on the critical path,
you must be able to establish an upper bound
for the time that it will take to complete.
I suspect that your supervisor thinks (s)he knows how to do that
for "conventional error-handling" but not
for the C++ exception handling mechanism.

Anyway, I used Google

http://www.google.com/

to search for

+"real-time programming" +"C++ exception handling"

and I found lots of stuff.

 

[John Carson]

Exceptions do *not* affect performance
unless an exception is encountered

That is compiler dependent. On VC++, there is a small performance cost even
when exceptions are not thrown.

 

[David Abrahams]

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
C++, 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?

Whether or not they are misinformed may depend on your compiler, and
it certainly depends on your definition of "big". Some relevant
information is at:

http://tinyurl.com/8rljh


--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Fabio Fracassi]

When I said that I'd prefer throwing and catching exceptions--and that,
in fact, exceptions is the "conventional error-handling technique" in
C++, 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?

I think the key here is "real-time system". The definition of performance in
real-time systems is slightly different. Real-time systems have to react in
a defined absolute time, in all cases.

I think that this is hard to guarantee when using exceptions (but probably
not impossible).

Exception performance depends on the compilers implementation of exceptions.
In the best case code that uses exceptions is faster in the "normal" (i.e.
no exception thrown) code path, but throwing an exceptions causes
overhead.

In most systems this is what you want. In real-time systems this additional
overhead can break your "reaction-time" guarantee

HTH

Fabio



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Gene Bushuyev]

....

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

Ideally you shouldn't have any overhead until the error occurs and exception
is actually thrown. But you need to do experiments with your compiler to
know for sure. I think most (all) compilers create some sort of exception
prolog for functions that may need stack unwinding when an exception is
thrown. How big an overhead does it introduce? My testing with VC7.1 on
several "tight" programs didn't show any impact of enabling/disabling
exceptions on run time as long as there are no errors and therefore no
exceptions. Throwing an exception can be expensive, but the functions that
return error codes should also do something with them, and in non-trivial
cases should clean up resources and propagate error codes to the site where
they can be processed. It may not be less expensive at all. Moreover, such
code quickly becomes unmaintainable, with convoluted control paths, and
flaky. As a result error codes are routinely ignored and error conditions
are not processed correctly. So there isn't really any alternative to
exceptions if you want to write safe and clear code.

- gene


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Maxim Yegorushkin]

[]

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

It's pretty much compiler specific. A good discussion about the issues can
be found in the paper at http://netlab.ru.is/exception/LinuxCXX.shtml

--
Maxim Yegorushkin
<[email protected]>

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[lilburne]

That is compiler dependent. On VC++, there is a small performance cost
even when exceptions are not thrown.

The main performance drag in error handling is the test for the error
condition. Remove the test and the need to handle exceptions goes away.

 

[Maxim Yegorushkin]

...

Ideally you shouldn't have any overhead until the error occurs and
exception
is actually thrown. But you need to do experiments with your compiler to
know for sure. I think most (all) compilers create some sort of exception
prolog for functions that may need stack unwinding when an exception is
thrown.

Please define that "most". This is true for MSVC, and false for g++.

... Moreover, such
code quickly becomes unmaintainable, with convoluted control paths, and
flaky. As a result error codes are routinely ignored and error conditions
are not processed correctly.

This is all fud and red herring we are all tired of.

--
Maxim Yegorushkin
<[email protected]>

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[David Abrahams]

...

Ideally you shouldn't have any overhead until the error occurs and exception
is actually thrown. But you need to do experiments with your compiler to
know for sure. I think most (all) compilers create some sort of exception
prolog for functions that may need stack unwinding when an exception is
thrown.

No, not "all," and IMO not even "most," but it probably depends on how
you count. A few do.

How big an overhead does it introduce? My testing with VC7.1

That one does on IA32, but not IA64.

on several "tight" programs didn't show any impact of
enabling/disabling exceptions on run time as long as there are no
errors and therefore no exceptions.

I agree with almost everything below...

Throwing an exception can be expensive, but the functions that
return error codes should also do something with them, and in
non-trivial cases should clean up resources and propagate error
codes to the site where they can be processed. It may not be less
expensive at all. Moreover, such code quickly becomes
unmaintainable, with convoluted control paths, and flaky. As a
result error codes are routinely ignored and error conditions are
not processed correctly. So there isn't really any alternative to
exceptions if you want to write safe and clear code.

.....except for that. Exceptions have great benefits in those areas,
but _that_ is overstating the case a bit.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[RH]

From the compiler's perspective, in the presence of exceptions (haven't
been disabled via command line), in the control flow graph (CFG) every
function call site gets an additional edge to a corresponding landing
pad (all implementation dependent, different nomenclature is used),
corresponding to the code that perform necessary cleanup code or
dispatch to the corresponding try blocks.

This can lead to missed other optimization opportunities. For example,
if such a call is in a loop, this loop now has an additional exit, and
certain transformation might just bail in such a scenario.

So, assuming one has a compiler with a no overhead implementation for
cases where no exception is thrown (which should be the default for
about every compiler out there by now) the overall performance question
- is very much benchmark dependent.

In our compiler lab, we try to compiler benchmarks with and without
exceptions - and always find some unexpected behavior. Some programs
get faster, others slower, sometimes caused by above mentioned
problems, sometimes by compiler problems - always interesting.

Exceptions are supposed to occur, well, under exceptional circumstances
only. I have seen people using them to get regular control flow... ;-)


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[John Carson]

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

On one interpretation, this is not necessarily bad advice. If, for example,
a
function processing user input can deal with invalid user input by prompting
the user to try again, then this is perfectly sensible. Exceptions are most
useful when errors cannot be dealt with locally and so the problem needs to
be propagated upwards until a point is reached where the error can be
handled.

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 C++, 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?

That is compiler specific. I suggest you run some tests to see what sort of
performance hit you get on your system. Note that other forms of error
handling carry their own performance costs.

--
John Carson


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[George Neuner]

I was told that since we have a real-time system, we can't afford
the performance hit caused by using exceptions.

Speaking from 10 years experience writing real time apps, I will say
that if your "real time" system really *is*, then I'm surprised it
would be using (m)any of the advanced features of C++ in the first
place. Virtual function calls, dynamic heap allocation and exception
handling are all, at best, problematic for verifying performance of
real time code.

I am *not* saying C++ is the wrong tool for such programming ... only
that it must be used judiciously. Many of the standard idioms and
practices are better suited for general application programming than
for real time programming. I'm not going to defend this point of view
here ... feel free to browse comp.arch.embedded for more than you ever
wanted to know about using C++ for real time programming.

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

The general thinking about exceptions views them as a rather low
frequency signal event rather than a standard control mechanism.
Exceptions were intended to provide a clean alternate path for error
handling ... which by itself implies no preference for the execution
path ... however, the working presumption has always been that the
error path was taken [much] less frequently.

Because of the presumption of infrequent use, many compiler vendors
did not put a lot of effort into making exception handling fast. This
makes exceptions more difficult to use in code which is routinely
expected to suffer failures - such as networking and hardware control
applications.

George

 

[Francis Glassborow]

Because of the presumption of infrequent use, many compiler vendors
did not put a lot of effort into making exception handling fast. This
makes exceptions more difficult to use in code which is routinely
expected to suffer failures - such as networking and hardware control
applications.

I think that is false. Rather the implementers have made major efforts
to minimise the cost for code that runs without raising an exception.
Normal code will run as fast as possible and the footprint will be kept
as small as possible. Those are the primary objectives for most
implementers. If possible the entire costs of an exception are paid when
an exception is actually raised. This cost will almost inevitably be
high. However, given that the program is in a problem state there seems
no reason to spend development resources reducing that cost when it
would likely remain high even with the most sophisticated
implementation.

In general programmers want normal code to run fast and in a small
space. It has always been made clear that the exception mechanism is NOT
intended as an alternative general return mechanism.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[kanze]

From the compiler's perspective, in the presence of exceptions
(haven't been disabled via command line), in the control flow
graph (CFG) every function call site gets an additional edge
to a corresponding landing pad (all implementation dependent,
different nomenclature is used), corresponding to the code
that perform necessary cleanup code or dispatch to the
corresponding try blocks.

This can lead to missed other optimization opportunities. For
example, if such a call is in a loop, this loop now has an
additional exit, and certain transformation might just bail in
such a scenario.

This is quite true in theory. In practice, however, I suspect
that there are very few, if any, compilers which optimize to a
point where this makes a difference.

Another point to keep in mind (although it probably isn't
relevant to embedded systems) is that exceptions make it very
easy for the compiler to isolate the clean-up code which is
called in the error case. This can, in turn, result if smaller
functions, increasing the probability of the function fitting
entirely in the cache.

In the end, you don't know until you've benchmarked. (EXcept
that as far as I know, the compilers I use don't allow turning
exceptions off.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Because of the presumption of infrequent use, many compiler vendors
did not put a lot of effort into making exception handling fast. This
makes exceptions more difficult to use in code which is routinely
expected to suffer failures - such as networking and hardware control
applications.

If I expect that some result occurs frequently as part of the normal usage,
I don't consider it exceptional, and then I do not use a exception for it.

 

[David Abrahams]

I think that is false.

Not from what I hear.

Rather the implementers have made major efforts
to minimise the cost for code that runs without raising an exception.
Normal code will run as fast as possible and the footprint will be kept
as small as possible. Those are the primary objectives for most
implementers. If possible the entire costs of an exception are paid when
an exception is actually raised. This cost will almost inevitably be
high. However, given that the program is in a problem state there seems
no reason to spend development resources reducing that cost when it
would likely remain high even with the most sophisticated
implementation.

In general programmers want normal code to run fast and in a small
space. It has always been made clear that the exception mechanism is NOT
intended as an alternative general return mechanism.

In a true real-time system, completing any operation in bounded and
well-understood time is crucial. If you use exception handling, you
are expecting to be able to handle exceptions and recover in a
reasonable way, or there's no point in writing the exception-handling
code in the first place. So "problem state" (whatever that means) or
no, it's important that throwing and handling an exception has
predictable performance in a real-time system.

All that said, I don't see why it should be so hard to measure the
performance of those exceptional paths and make an informed decision
on acceptability.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[msalters]

RH schreef:

been disabled via command line), in the control flow graph (CFG) every
function call site gets an additional edge to a corresponding landing
pad (all implementation dependent, different nomenclature is used),
corresponding to the code that perform necessary cleanup code or
dispatch to the corresponding try blocks.

This can lead to missed other optimization opportunities. For example,
if such a call is in a loop, this loop now has an additional exit, and
certain transformation might just bail in such a scenario.

No, it doesn't have an additional exit. The "error return value" case
will have an 'if( value==bad ) break;' statement. That is the same
exit from the loop.

In addition, this exit is more clearly recognizable as exceptional if
it's an exception. Which in turn means the compiler can put that
part of the code aside, keeping the actual loop tight.

Still: the best part of exceptions is a debugger with a 'break on
exceptions' feature. Error returns cause a performance hit on my
debugging time, and that's more than a few microseconds.

Regards, Michiel Salters


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[George Neuner]

If I expect that some result occurs frequently as part of the normal usage,
I don't consider it exceptional

I agree with that philosophy. Personally I never equated the term
"exception" with "error", to me it always meant "unexpected". As far
as I'm concerned, predictable errors are not exceptions. However,
other definitions prevailed.


Anyway, the whole point of the exception mechanism was to clearly
separate the success path from the failure path so that code could be
written along each path assuming a particular program state and not
having to write code for all cases at each state decision point.

But, as I said previously, there was a presumption that the failure
path was taken with low frequency. The problem with that approach is
that there are applications for which failure is not only expected,
but for which success is the rare case that occurs only if everything
that could go wrong doesn't. Such applications are not rare and it
should be distressing to everyone that the "conventional
error-handling technique" [ OP's words ] in C++ is not well suited to
use in them ... at least as it is currently implemented by most
compilers.

and then I do not use a exception for it.

But if you don't use the "conventional" techniques, the "standard"
idioms and the "well known" patterns, then your code is harder for
others to understand and maintain.

FWIW: in such a case I wouldn't use exceptions either.


George