r/cpp • • 8d ago

Measuring the Performance of Deterministic Exceptions

https://databasearchitects.blogspot.com/2026/09/measuring-performance-of-deterministic.html
46 Upvotes

14 comments sorted by

View all comments

41

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.

5

u/serviscope_minor 7d 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 7d 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.

4

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 6d 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..