I was watching Systematic Error Handling in C++—Andrei Alexandrescu he claims that Exceptions in C++ are very very slow.

Is this still true for C++98?

  • 45
    It makes no sense to ask if "C++98 exceptions" are faster/slower than "C++03 exceptions" or "C++11 exceptions". Their performance is dependent on how the compiler implements them in your programs, and the C++ standard says nothing about how they should be implemented; the only requirement is that their behavior must follow the standard (the "as-if" rule). – In silico Dec 12 '12 at 8:43
  • Related (but not really duplicate) question: stackoverflow.com/questions/691168/… – Philipp Dec 12 '12 at 8:46
  • 2
    yes, it is very slow, but they should not be thrown for a normal operations or used as a branch – BЈовић Dec 12 '12 at 8:46
  • I've found a similar question. – PaperBirdMaster Dec 12 '12 at 8:55
  • To clarify what BЈовић has said, using exceptions is not something to be scared of. It is when an exception is thrown that you encounter (potentially) time consuming operations. I am also curious as to why you want to know for C++89 specifically... that latest version is C++11, and the time that it takes for exceptions to run is implementation defined, hence my 'potentially' time consuming. – thecoshman Dec 12 '12 at 8:56

The main model used today for exceptions (Itanium ABI, VC++ 64 bits) is the Zero-Cost model exceptions.

The idea is that instead of losing time by setting up a guard and explicitly checking for the presence of exceptions everywhere, the compiler generates a side table that maps any point that may throw an exception (Program Counter) to the a list of handlers. When an exception is thrown, this list is consulted to pick the right handler (if any) and stack is unwound.

Compared to the typical if (error) strategy:

  • the Zero-Cost model, as the name implies, is free when no exceptions occur
  • it costs around 10x/20x an if when an exception does occur

The cost, however, is not trivial to measure:

  • The side-table is generally cold, and thus fetching it from memory takes a long time
  • Determining the right handler involves RTTI: many RTTI descriptors to fetch, scattered around memory, and complex operations to run (basically a dynamic_cast test for each handler)

So, mostly cache misses, and thus not trivial compared to pure CPU code.

Note: for more details, read the TR18015 report, chapter 5.4 Exception Handling (pdf)

So, yes, exceptions are slow on the exceptional path, but they are otherwise quicker than explicit checks (if strategy) in general.

Note: Andrei Alexandrescu seems to question this "quicker". I personally have seen things swing both ways, some programs being faster with exceptions and others being faster with branches, so there indeed seems to be a loss of optimizability in certain conditions.

Does it matter ?

I would claim it does not. A program should be written with readability in mind, not performance (at least, not as a first criterion). Exceptions are to be used when one expects that the caller cannot or will not wish to handle the failure on the spot, and pass it up the stack. Bonus: in C++11 exceptions can be marshalled between threads using the Standard Library.

This is subtle though, I claim that map::find should not throw but I am fine with map::find returning a checked_ptr which throws if an attempt to dereference it fails because it's null: in the latter case, as in the case of the class that Alexandrescu introduced, the caller chooses between explicit check and relying on exceptions. Empowering the caller without giving him more responsibility is usually a sign of good design.

Is this answer outdated?
  • 3
    +1 I would only add four things: (0) about the support for rethrowing added in C++11; (1) a reference to committee's report on c++ efficiency; (2) some remarks about correctness (as trumping even readability); and (3) about the performance, remarks about measuring it against the case of not using exceptions (all is relative) – Cheers and hth. - Alf Dec 12 '12 at 10:54
  • 2
    @Cheersandhth.-Alf: (0), (1) and (3) done: thanks. Regarding correctness (2), while it trumps readability I am unsure about exceptions leading to more correct code than other error-handling strategies (it's so easy to forget about the many invisible paths of execution exceptions create). – Matthieu M. Dec 12 '12 at 13:21
  • 2
    The description may be locally correct, but it may be worth noting that the presence of exceptions has global implications on assumptions and optimizations the compiler can make. These implications suffer the problem that they have "no trivial counter-examples", since the compiler can always see through a small program. Profiling on a realistic, large code base with and without exceptions may be a good idea. – Kerrek SB Jul 18 '15 at 1:55
  • 4
    > the Zero-Cost model, as the name implies, is free when no exception occurs this is not actually true down to the finest levels of detail. generating more code always has a performance impact, even if small and subtle... it might take a tiny bit longer for the OS to load the executable, or you will get more i-cache misses. also, what about stack unwinding code? also, what about the experiments that you can do to measure the effects instead of trying to understand it with rational thought? – jheriko Sep 30 '15 at 16:33
  • 2
    @jheriko: I believe I addressed most of your questions already, actually. The time to load should not be impacted (cold code should not be loaded), the i-cache should not be impacted (cold code should not make it into the i-cache), ... so to address the one missing question: "how to measure" => replacing any exception thrown with a call to abort will allow you to measure the binary-size footprint and check that the load-time/i-cache behave similarly. Of course, better not hit any of the abort... – Matthieu M. Sep 30 '15 at 17:18

When the question was posted I was on my way to the doctor, with a taxi waiting, so I only had time then for a short comment. But having now commented and upvoted and downvoted I’d better add my own answer. Even if Matthieu’s answer already is pretty good.

Are exceptions especially slow in C++, compared to other languages?

Re the claim


If that’s literally what Andrei claims, then for once he’s very misleading, if not downright wrong. For a raised/thrown exceptions is always slow compared to other basic operations in the language, regardless of the programming language. Not just in C++ or more so in C++ than in other languages, as the purported claim indicates.

In general, mostly regardless of language, the two basic language features that are orders of magnitude slower than the rest, because they translate to calls of routines that handle complex data structures, are

  • exception throwing, and

  • dynamic memory allocation.

Happily in C++ one can often avoid both in time-critical code.

Unfortunately There Ain’t No Such Thing As A Free Lunch, even if the default efficiency of C++ comes pretty close. :-) For the efficiency gained by avoiding exception throwing and dynamic memory allocation is generally achieved by coding at a lower level of abstraction, using C++ as just a “better C”. And lower abstraction means greater “complexity”.

Greater complexity means more time spent on maintenance and little or no benefit from code reuse, which are real monetary costs, even if difficult to estimate or measure. I.e., with C++ one can, if so desired, trade some programmer efficiency for execution efficiency. Whether to do so is largely an engineering and gut-feeling decision, because in practice only the gain, not the cost, can be easily estimated and measured.

Are there any objective measures of C++ exception throwing performance?

Yes, the international C++ standardization committee has published a Technical Report on C++ performance, TR18015.

What does it mean that exceptions are “slow”?

Mainly it means that a throw can take a Very Long Time™ compared to e.g. an int assignment, due to the search for handler.

As TR18015 discusses in its section 5.4 “Exceptions” there are two principal exception handling implementation strategies,

  • the approach where each try-block dynamically sets up exception catching, so that a search up the dynamic chain of handlers is performed when an exception is thrown, and

  • the approach where the compiler generates static look-up tables that are used to determine the handler for a thrown exception.

The first very flexible and general approach is almost forced in 32-bit Windows, while in 64-bit land and in *nix-land the second far more efficient approach is commonly used.

Also as that report discusses, for each approach there are three main areas where exception handling impacts on efficiency:

  • try-blocks,

  • regular functions (optimization opportunities), and

  • throw-expressions.

Mainly, with the dynamic handler approach (32-bit Windows) exception handling has an impact on try blocks, mostly regardless of language (because this is forced by Windows' Structured Exception Handling scheme), while the static table approach has roughly zero cost for try-blocks. Discussing this would take a lot more space and research than is practical for an SO answer. So, see the report for details.

Unfortunately the report, from 2006, is already a little bit dated as of late 2012, and as far as I know there’s not anything comparable that’s newer.

Another important perspective is that the impact of use of exceptions on performance is very different from the isolated efficiency of the supporting language features, because, as the report notes,

“When considering exception handling, it must be contrasted to alternative ways of dealing with errors.”

For example:

  • Maintenance costs due to different programming styles (correctness)

  • Redundant call site if failure checking versus centralized try

  • Caching issues (e.g. shorter code may fit in cache)

The report has a different list of aspects to consider, but anyway the only practical way to obtain hard facts about the execution efficiency is probably to implement the same program using exception and not using exceptions, within a decided cap on development time, and with developers familiar with each way, and then MEASURE.

What is a good way to avoid the overhead of exceptions?

Correctness almost always trumps efficiency.

Without exceptions, the following can easily happen:

  1. Some code P is meant to obtain a resource or compute some information.

  2. The calling code C should have checked for success/failure, but doesn't.

  3. A non-existent resource or invalid information is used in code following C, causing general mayhem.

The main problem is point (2), where with the usual return code scheme the calling code C is not forced to check.

There are two main approaches that do force such checking:

  • Where P directly throws an exception when it fails.

  • Where P returns an object that C has to inspect before using its main value (otherwise an exception or termination).

The second approach was, AFAIK, first described by Barton and Nackman in their book *Scientific and Engineering C++: An Introduction with Advanced Techniques and Examples, where they introduced a class called Fallow for a “possible” function result. A similar class called optional is now offered by the Boost library. And you can easily implement an Optional class yourself, using a std::vector as value carrier for the case of non-POD result.

With the first approach the calling code C has no choice but to use exception handling techniques. With the second approach, however, the calling code C can itself decide whether to do if based checking, or general exception handling. Thus, the second approach supports making the programmer versus execution time efficiency trade-off.

What is the impact of the various C++ standards, on exception performance?

“I want to know is this still true for C++98”

C++98 was the first C++ standard. For exceptions it introduced a standard hierarchy of exception classes (unfortunately rather imperfect). The main impact on performance was the possibility of exception specifications (removed in C++11), which however were never fully implemented by the main Windows C++ compiler Visual C++: Visual C++ accepts the C++98 exception specification syntax, but just ignores exception specifications.

C++03 was just a technical corrigendum of C++98. The only really new in C++03 was value initialization. Which has nothing to do with exceptions.

With the C++11 standard general exception specifications were removed, and replaced with the noexcept keyword.

The C++11 standard also added support for storing and rethrowing exceptions, which is great for propagating C++ exceptions across C language callbacks. This support effectively constrains how the current exception can be stored. However, as far as I know that does not impact on performance, except to the degree that in newer code exception handling may more easily be used on both sides of a C language callback.

Is this answer outdated?
  • 7
    "exceptions is always slow compared to other basic operations in the language, regardless of the programming language"... except in languages designed to compile use of exceptions into ordinary flow control. – Ben Voigt Dec 12 '12 at 14:54
  • 5
    "throwing an exception involves both allocation and stack unwinding". That is also obviously not true in general and, again, OCaml is a counter example. In garbage collected languages there is no need to unwind the stack because there are no destructors so you just longjmp to the handler. – J D Mar 19 '14 at 21:16
  • 2
    @JonHarrop: presumably you're unaware that Pyhon has a finally-clause for exception handling. this means a Python implementation either has stack unwinding or is not Python. you appear to be completely ignorant of the subjects that you make (fantasy) claims about. sorry. – Cheers and hth. - Alf Mar 20 '14 at 19:07
  • 2
    @Cheersandhth.-Alf: "Pyhon has a finally-clause for exception handling. this means a Python implementation either has stack unwinding or is not Python". The try..finally construct can be implemented without stack unwinding. F#, C# and Java all implement try..finally without using stack unwinding. You just longjmp to the handler (as I already explained). – J D Mar 20 '14 at 21:37
  • 4
    @JonHarrop: you sound like posing a dilemma. but it has no relevance i can see to anything so far discussed, and so far you have posted a long sequence of negative-sounding nonsense. i would have to trust you in order to agree or not with some vague wording, because as antagonist you are choosing what you will reveal that it "means", and i certainly don't trust you after all that meaningless nonsense, downvoting etc. – Cheers and hth. - Alf Mar 22 '14 at 11:11

You can never claim about performance unless you convert the code to the assembly or benchmark it.

Here is what you see: (quick-bench)

The error code is not sensitive to the percentage of occurrence. Exceptions have a little bit overhead as long as they are never thrown. Once you throw them, the misery starts. In this example, it is thrown for 0%, 1%, 10%, 50% and 90% of the cases. When the exceptions are thrown 90% of the time, the code is 8 times slower than the case where the exceptions are thrown 10% of the time. As you see, the exceptions are really slow. Do not use them if they are thrown frequently. If your application has no real-time requirement, feel free to throw them if they occur very rarely.

You see many contradictory opinions about them. But finally, are exceptions are slow? I don't judge. Just watch the benchmark.

C++ exceptions performance benchmark

Is this answer outdated?

It depends on the compiler.

GCC, for example, was known for having very poor performance when handling exceptions, but this got considerably better in the past few years.

But note that handling exceptions should - as the name says - be the exception rather than the rule in your software design. When you have an application which throws so many exceptions per second that it impacts performance and this is still considered normal operation, then you should rather think about doing things differently.

Exceptions are a great way to make code more readable by getting all that clunky error handling code out of the way, but as soon as they become part of the normal program flow, they become really hard to follow. Remember that a throw is pretty much a goto catch in disguise.

Is this answer outdated?
  • -1 re the question as it stands now, "is this still true for C++98", that certainly does not depend on the compiler. also, this answer's throw new Exception is a Java-ism. one should as a rule never throw pointers. – Cheers and hth. - Alf Dec 12 '12 at 8:59
  • 1
    does the 98 standard dictate exactly how exceptions are to be implemented? – thecoshman Dec 12 '12 at 9:00
  • 6
    C++98 is a ISO standard, not a compiler. There are many compilers which implement it. – Philipp Dec 12 '12 at 9:00
  • 3
    @thecoshman: No. The C++ standard says nothing about how anything should be implemented (with the possible exception of the "Implementation Limits" part of the standard). – In silico Dec 12 '12 at 9:01
  • 2
    @Insilico then I can only draw the logical conclusion that (shockingly) it is implementation defined (read, compiler specific) how exceptions perform. – thecoshman Dec 12 '12 at 9:03

Yes, but that doesn't matter. Why?
Read this:

Basically that says that using exceptions like Alexandrescu described (50x slowdown because they use catch as else) is just wrong. That being said for ppl who like to do it like that I wish C++22 :) would add something like:
(note this would have to be core language since it is basically compiler generating code from existing one)

result = attempt<lexical_cast<int>>("12345");  //lexical_cast is boost function, 'attempt'
//... is the language construct that pretty much generates function from lexical_cast, generated function is the same as the original one except that fact that throws are replaced by return(and exception type that was in place of the return is placed in a result, but NO exception is thrown)...     
//... By default std::exception is replaced, ofc precise configuration is possible
if (result)
     int x = result.get(); // or result.result;
     // even possible to see what is the exception that would have happened in original function
     switch (result.exception_type())


P.S. also note that even if the exceptions are that slow... it is not a problem if you dont spend a lot of time in that part of the code during execution... For example if float division is slow and you make it 4x faster that doesnt matter if you spend 0.3% of your time doing FP division...

Is this answer outdated?

Like in silico said its implementation dependent, but in general exceptions are considered slow for any implementation and shouldn't be used in performance intensive code.

EDIT: I'm not saying don't use them at all but for performance intensive code it is best to avoid them.

Is this answer outdated?
  • 10
    This is at best a very simplistic way of looking at exception performance. For example, GCC uses a "zero-cost" implementation where you don't incur a performance hit if no exceptions are thrown. And exceptions are meant for exceptional (i.e. rare) circumstances, so even if they are slow by some metric that's still not enough reason to not use them. – In silico Dec 12 '12 at 8:49
  • @insilico if you look at why I said, I did not say not to use exceptions full stop. I specified performance intensive code, this is an accurate assessment, I mainly do work with gpgpus and I wud be shot if I used exceptions. – Chris McCabe Dec 12 '12 at 9:38

Your Answer

