The Nemerle guys point out that exception handling is not quite fast as they'd like in Mono and the other CLR implementations and assume it's a design issue of .Net.
I can't say about other implementations, but as far as Mono is concerned, we were busy writing a couple million other lines of code and exception handling speed is of little importance when compared to the amount of work we did and the amount of work we have ahead of us. That said, making some particular exception handling pattern work faster is easy and in fact I just committed a change that makes the posted test case 4 times faster. The trick is to either throw objects that don't derive from System.Exception or to throw already thrown exception objects: in both cases we don't need to get the stack trace info, which is what currently slows down exception handling.
Of course we'll speedup the code when we'll have more time to dedicate to fringe performance areas (the changes are not a 1-liner as the change just committed:-).
The code could be optimized more, for another 2x speedup, if someone is willing to dedicate the time.
Anyway, this issue reminded me of a similar issue that IronPython exposed: when Jim gave his talk at OSCon, there was an embarassing case of exception handling in the pie-thon benchmark where Mono resulted 100 times slower than CPython. A few days after we knew about the issue, I committed some changes to reduce the overhead to more sane levels (we are now about 8 times slower in that particular sub-benchmark and again most of the time is spent gathering stack trace info).
It's interesting to note how the Mono performance improved for the pie-thon bench since IronPython was released. In his slides he mentions Mono 1.0 was 23 times slower than CPython
(2 times slower if the exception-handling bench is not considered). A few days later I posted at http://lambda-the-ultimate.org/ the numbers using mono from cvs (what was to become 1.1.x) and there were already some improvements, with mono 1.8 slower than CPython (without the dreaded b5 test).
Today I rerun the benchmark and the numbers have improved a lot: Mono is now 2 times slower than CPython including the heavy exception handling test. The nice related result is that mono is 10% faster than CPython if b5 is excluded. This amounts to a general 2x speedup in a little over 6 months.
This gets us back to the discussion about the design of .net/mono and exception handling speed. There is nothing in the general design that would make exception handling particularly slow, but of course the virtual machine is not built around the need to make exception handling fast, and for good reasons. As Jim quotes in his slides from the Modula-3 manual:
``Implementations should speed up normal outcomes at the expense of exceptions ... Expending a thousand instructions per exception raised to save one instruction per procedure call would be reasonable.''
One of the reasons IronPython could implement the Python semantics with good performance on Mono is because Mono and the .Net design allow for very fast method calls. Contrast this with, for example, the design of Parrot, where method calls and returns are built around the concept of continuations. This makes exception handling in parrot probably almost as fast as method calls, but normal calls are also made one or two orders of magnitude slower than in Mono.
We'll see more speedups in Mono's exception handling, but people should consider that exception handling will always be about two orders of magnitude slower than a simple method call (well, except for some special cases that we plan to optimize, where they'll be comparable:-).