Performance of exception handling

[Jonathan M Davis]

> Hi,
> 
> I'm doing some benchmarks (DMD 2.052 on Linux), and noticed that exception
> handling is terrible slow even on quite fast hardware.
> 
> There is a note on DM's site, saying:
> 
> "Because errors are unusual, execution of error handling code is not
> performance critical."
> 
> Well, sure this is (somehow) true, but *so* slow? In my tests, Xeon 3.4 GHz
> is able to handle only ca. 1000 exceptions/s (!). 1ms for single exception
> is a little bit too much, especially when application needs to recover
> fast, not to mention that on slower hardware (like Atom) it will be really
> slow.
> 
> And, since some exceptions are not so unusual in normal flow (file not
> found, connection reset etc), "not performance critical" is not really
> applicable. Simple example - in case of web (or any other) server with
> high load, socket exceptions of any kind are quite common. It is still
> natural to use try/catch to handle them, but it will slow down everything
> else (imagine > 1K connections/s and 10% cut rate).
> 
> So, my question - is there something, that can improve performance? Any
> clues where to dig for this?

Yeah. Exceptions are _slow_. I ran into some problems with that when reworking 
the unit tests in std.datetime. I can barely use assertThrown or it takes the 
performance of the unit tests. It takes something like 450 times longer to run 
a line of code that ends up throwing an exception to be caught by assertThrown 
than it does if it does if a similar call which doesn't thrown that is wrapped 
by assertNotThrown. So, as far as unit tests are concerned, improving 
exception performance would be a big boost. Exceptions are bound to be slower, 
but 450 times slower is an enormous slowdown. If that could be sped up, that 
would be great.

- Jonathan M Davis