Exceptions performance penalty

  • Thread starter Michael Andersson
  • Start date
M

Michael Andersson

Hi!
Does the use of exception handling induce a performance penalty during
the execution of non exception handling code?

Regards,
/Michael
 
O

Oliver S.

Does the use of exception handling induce a performance penalty
during the execution of non exception handling code?

The performacne-penalty is usually very slight;
not worth to be mentioned.
 
P

Peter van Merkerk

Does the use of exception handling induce a performance penalty during
the execution of non exception handling code?

It depends on which compiler yuo are using. There are several ways a
compiler can deal with exceptions so there is no standard answer to this. On
some compilers there is no performance penalty as long as no exception is
thrown. On others there is always a certain performance penalty, even when
no exceptions are thrown.
 
H

Hafiz Abid Qadeer

Peter van Merkerk said:
It depends on which compiler yuo are using. There are several ways a
compiler can deal with exceptions so there is no standard answer to this. On
some compilers there is no performance penalty as long as no exception is
thrown. On others there is always a certain performance penalty, even when
no exceptions are thrown.

In C++ Programming Language 3rd edition section 14.8 Stroustrup writes
that it is possible to implement exception handling in such a way that
there is no run time overhead when no exception is thrown but it is
hard.
There is generally some overhead as we have to keep trach for the
local objects whose constructors have run, so when exception is thrown
their destructors are called. Their is detailed discussion about this
in "More effective C++" by Scott Meyer
 
P

Peter van Merkerk

Does the use of exception handling induce a performance penalty
during
In C++ Programming Language 3rd edition section 14.8 Stroustrup writes
that it is possible to implement exception handling in such a way that
there is no run time overhead when no exception is thrown but it is
hard.

It may be hard (but so is writing a C++ compiler), but there are C++
compilers which have implemented zero runtime overhead when no
exceptions are thrown.
There is generally some overhead as we have to keep trach for the
local objects whose constructors have run, so when exception is thrown
their destructors are called. Their is detailed discussion about this
in "More effective C++" by Scott Meyer

The same book also tells you not to take the performance penalty
estimation too seriously, as thing may improve in the future. This book
is already several years old, and things have improved compared to when
it was written.

The bottom line is that your mileage may vary; it depends on the C++
compiler you are using.
 
S

stelios xanthakis

In C++ Programming Language 3rd edition section 14.8 Stroustrup writes
that it is possible to implement exception handling in such a way that
there is no run time overhead when no exception is thrown but it is
hard.
There is generally some overhead as we have to keep trach for the
local objects whose constructors have run, so when exception is thrown
their destructors are called. Their is detailed discussion about this
in "More effective C++" by Scott Meyer

AFAIK, this is already done (in g++ at least).

It creates exception tables. From the value of program counter
you can understand in which function/scope you're in. For each
scope you already know which destructors have to be called and
using the stack address you delete the apropriate objects.

We suppose that you can get __builtin_return_address (LEVEL)
and __builtin_frame_address (LEVEL) for the ESP and EPC of the
caller of level LEVEL.

stelios
 
O

Oliver S.

AFAIK, this is already done (in g++ at least).
It creates exception tables. From the value of program counter
you can understand in which function/scope you're in. For each
scope you already know which destructors have to be called and
using the stack address you delete the apropriate objects.

That's something I already thought of and I had the idea that the
supporting data-structure would make it possible to determine which
exception-specifiers take effect when the exception is thrown so that
ESs could be supported without any peformance penalty ! That wouldn't
be a reason to love the callow ES-concept, but I think that when the
performance-decreasing effect could be eliminated, they clearly would
be an advantage.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top