6

Possible Duplicate:
Measuring exception handling overhead in C++
Performance when exceptions are not thrown (C++)

I have heard anecdotally that using "try" blocks in C++ slows down the code at run-time even if no exceptions occur. I have searched but have been unable to find any explanation or substantiation for this. Does anyone know if this is true & if so why?

Community
  • 1
  • 1
GigaQuantum
  • 331
  • 2
  • 7
  • 1
    I think this: http://stackoverflow.com/questions/691168/how-much-footprint-does-c-exception-handling-add will answer your question. – Alex Kremer Jan 10 '12 at 14:57
  • 1
    have a look at this question: http://stackoverflow.com/questions/43253/measuring-exception-handling-overhead-in-c – codeling Jan 10 '12 at 14:58
  • 3
    ¤ See the C++ Standardization Committee's [Technical Report on C++ Performance (ISO/IEC TR 18015:2006 C++ Performance - draft TR)](http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf). Essentially, it depends on the way exception handling is implemented, which in turn depends on assumptions about what will happen most often. Cheers & hth., – Cheers and hth. - Alf Jan 10 '12 at 15:08
  • I think that if you aren't developing a really performance critical code, then you just don't have to care about the EH overhead, it so negligible when using nowadays compilers and CPUs... Much more important is to avoid memory leaking, which isn't always trivial in C++. – vitakot Jan 10 '12 at 15:09
  • thanks - i clearly didn't hit on the right keywords in my searches to find those earlier Qs. appreciate the links. – GigaQuantum Jan 10 '12 at 16:20

2 Answers2

17

The answer, as usually, is "it depends".

It depends on how exception handling is implemented by your compiler.

If you're using MSVC and targeting 32-bit Windows, it uses a stack-based mechanism, which requires some setup code every time you enter a try block, so yes, that means you incur a penalty any time you enter such a block, even if no exception is thrown.

Practically every other platform (other compilers, as well as MSVC targeting 64-bit Windows) use a table-based approach where some static tables are generated at compile-time, and when an exception is thrown, a simple table lookup is performed, and no setup code has to be injected into the try blocks.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • 1
    But inserting try/catch will disable optimizations (to a degree) in any (correct) optimizing compiler. – Hot Licks Jan 10 '12 at 18:23
  • Huh? Which optimizations do you mean, and why? – jalf Jun 25 '13 at 07:22
  • 1
    You name it -- loop optimizations (if the try/catch is in the loop), common subexpression elimination, etc. The compiler must assume that the code could jump from any point in the try range to the catch block, so it can't very easily optimize across the try range boundary. – Hot Licks Jun 25 '13 at 11:29
6

There are two common ways of implementing exceptions.

One, sometimes refered to as "table-based" or "DWARF", uses static data to specify how to unwind the stack from any given point; this has no runtime overhead except when an exception is thrown.

The other, sometime referred to as "stack-based", "setjmp-longjmp" or "sjlj", maintains dynamic data to specify how to unwind the current call stack. This has some runtime overhead whenever you enter or leave a try block, and whenever you create or destroy an automatic object with a non-trivial destructor.

The first is more common in modern compilers (certainly GCC has done this by default for many years); you'll have to check your compiler documentation to see which it uses, and whether it's configurable.

Mike Seymour
  • 249,747
  • 28
  • 448
  • 644
  • `DWARF` is only used for debugging information AFAIK, never for unwind data – Hasturkun Jan 10 '12 at 15:43
  • 1
    @Hasturkun: The information needed to unwind the stack is the same as (some of) the information needed for debugging, so at least GCC and LLVM use DWARF for both, and sometimes refer to table-based handling as "DWARF handling". – Mike Seymour Jan 10 '12 at 16:30