[llvm-dev] Exceptions and performance

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 14 07:55:04 PDT 2020

On 14/08/2020 03:39, David Blaikie via llvm-dev wrote:
> Once you get past the nothrow default problems, then you probably have
> to deal with the performance tradeoffs between the current strategy
> for exception implementations (table based, etc) compared to the
> tradeoffs for explicit error handling. You'd probably find that using
> exceptions for/every/  error return would not be the right perf
> tradeoff for many use cases where errors are at least somewhat common.
> So you'd probably end up with a hybrid solution - some things using
> exceptions where the failure is rare/going to be costly anyway
> (stopping the process, showing an error to a user/asking for user
> input about retrying, etc) and then still using explicit error
> handling for other things.

There's a second-order effect here too.  Everyone knows exceptions are 
slow, so everyone writes fast-path code with explicit error returns.  As 
a result, modern branch predictors are *really* good at predicting the 
no-error case.  A lot of the arguments about checked return values being 
slow date back to in-order processors where adding any instructions on 
the fast path was always a slowdown, even if they were not-taken branches.

I did some experiments about a year ago with different hand-written 
assembly implementations of error handling control flow patterns and it 
was really hard to beat the checked return on recent Intel hardware. 
This was a microbenchmark, so didn't see effects from increased cache usage.

There's also the fact that explicit error checking lets the programmer 
simplify the CFG explicitly.  If you're calling two functions that don't 
depend on any data flow between them, you can do something like:

auto a = someFn();
auto b = someOtherFn();
if (!a || !b)

Transforming exception-driven code into this structure would be an 
invalid transform unless the compiler could prove that someOtherFn() has 
no observable side effects.


More information about the llvm-dev mailing list