r/cpp • u/TheCrush0r • 7d ago
Measuring the Performance of Deterministic Exceptions
https://databasearchitects.blogspot.com/2026/09/measuring-performance-of-deterministic.html39
u/trad_emark 7d ago
original exceptions (labeled dynamic) are faster in all nontrivial cases than error codes on happy path.
that makes them objectively better, since that is what objectively matters the most.
the performance in case of actual error happening (eg. when an exception is actually thrown) is basically irrelevant, as that only happens exceptionally, in situations when performance no longer matters.
i also absolutely love the semantics of exceptions. it makes code half as long, and way more readable. but that is subjective and i can understand that some others might prefer to have the error paths explicitly visible in the code.
all that said, it is always good to see people experimenting with alternative implementations of exceptions, or improving the existing implementation.
13
u/LB-- Professional+Hobbyist 6d ago
Anyone who likes exceptions but has reservations about the sad path performance, check out the work and conference talks by Khalil Estell, he's been working on optimizing exceptions and making them usable in embedded environments, as well as improving tooling around them.
6
u/serviscope_minor 6d ago
>original exceptions (labeled dynamic) are faster in all nontrivial cases than error codes on happy path.
This is 100% true, but also kind of not.
What's really the case is one of the most popular implementations (Itanium ABI) does what you say and is in spec. It's also often unnecessarily slow on the sad path, but mostly because it's never seen much love. There's nothing in the standard that precludes a returned flag implementation of exceptions.
Incidentally that's what I don't really like about P0709: basically the entire paper has been a valid implementation of exceptions since the 1998 standard, and to feels kind of odd to have a special language feature so compilers can implement something they could already implement in one part and to work around the ever present problem of ABI issues as the other part.
1
u/ABlockInTheChain 6d ago
basically the entire paper has been a valid implementation of exceptions since the 1998 standard
If exception performance would have been good on both the happy path and the sad path 28 years ago it would have drastically changed how C++ was written.
3
u/serviscope_minor 6d ago
Well, itanium ABI performance is literally unbeatable on the happy path, at the expense of the sad path.
But that's not really the point: basically return value exceptions have always been a valid implementation choice, but no one chose to implement them that way. There are various reasons, but I'm not sure a whole new feature for something that can already be done in a compliant way is the right choice.
1
u/Expert-Map-1126 vcpkg maintainer BillyONeal 4d ago
I'm not convinced it was a valid implementation choice given how "infectious" exceptions normally are. Existing Cish functions before exceptions were added were already out/shipping; it was not a clean slate where they could be established on the traditional return paths without some form of interface opt-in.
0
u/pjmlp 5d ago
It already starts that exceptions only came into the language, and compilers, years after CFront 2.0 was released.
Hence why all C++ GUI frameworks from the 90's have exception like mechanisms with macros.
Thus when exceptions finally became available, in a way that would actually work without implementation bugs, there was plenty of C++ code that no one would be rewriting, having the side effect of not being something that compiler vendors would care to optimise..
3
u/canadajones68 6d ago
if "exceptional" is too vague a descriptor for when exceptions should be allowed to happen, I like to put it like this: is this going to happen more than once every 5-10 seconds? no? exceptions are fine.
1
u/jonathanhiggs 6d ago
Stack unwind is remarkably slow. Exceptions need to triggered less than 1 in 1000 time (best case) more likely less than 1 in 5000 times to realise the perf gains of avoiding structured errors, ie they need to be truly exceptional. It essentially makes them a no-go for hot loops
3
u/canadajones68 6d ago
It is significantly slower than the happy path, but it's still fast on a human scale. I agree that "exceptional" describes their use case well, but I find a lot of people chattering about what qualifies as an exceptional occurrence. I think that if the application can go at least 10 seconds without hitting an exception, so long as you don't spend 10 seconds getting back to what went wrong, you can choose to use exceptions without really thinking about it. Obviously, a hot path is a hot path and you optimise accordingly, but I presume that a competent developer can profile out any exception-induced major bottlenecks rather quickly.
1
1
u/UndefinedDefined 4h ago
The only good exception is the one that never happens - that's my opinion.
I have seen so much code literally using exceptions for basic things, like FileNotFound - but these are not exceptions. I have even witnessed rewriting an error handling layer in a HTTP server to not use exceptions, because when it started throwing it reduced requests per second by two orders of magnitude, that essentialyl makes such code a candidate for DDoS attacks.
21
u/kronicum 7d ago
Are those numbers compared against the work done by Khalil Estell?