Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are Exceptions in C++ really slow

Tags:

c++

c++98

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?

like image 794
Avinash Avatar asked Dec 12 '12 08:12

Avinash


People also ask

Do exceptions slow down code?

If not used correctly, exceptions can slow down your program, as it takes memory and CPU power to create, throw, and catch exceptions. If overused, they make the code difficult to read and frustrating for the programmers using the API.

Is exception handling cheap and efficient?

As a rule of thumb, exception handling is extremely cheap when you don't throw an exception. It costs nothing on some implementations. All the cost is incurred when you throw an exception: that is, “normal code” is faster than code using error-return codes and tests. You incur cost only when you have an error.

Are exceptions slow C#?

One simple answer to the question which as actually asked is..... On Windows CLR, exceptions are 750 times slower than return values.

Is exception handling in C++ efficient?

Exceptions aren't all bad. In fact, they are extremely performant at what they are designed for: exceptional circumstances! We only start running into problems when we use them for general control flow, where much more efficient solutions are already available.


1 Answers

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.

like image 185
Matthieu M. Avatar answered Oct 11 '22 17:10

Matthieu M.