exceptions performance (Re: [Mono-devel-list] JIT profiling/benchmarking)

Paolo Molaro lupus at ximian.com
Sat Jan 3 17:37:29 EST 2004


On 01/03/04 Michal Moskal wrote:
> It is quite common for (at least some) functional languages to use
> exceptions for ordinary control flow. Now when writing compiler for such
> a language, do I need to invent my own exception handling techniques?
> (for example some exceptions will never go out one function and it can be
> determined statically, so it can be replaced with goto).
> 
> How fast (slow?) are exceptions?

The only way to know is to write a test case that reproduces what you'd
use exceptiosn for and benchmark it.
Exception throw/catch has not been optimized in mono afaik: it's
possible there are some low hanging optimizations tricks we could use if
the performance of exception handling becomes an issue in some setup,
liek the one you describe.
Anyway, we're interested in seeing benchmarks: once you see the numbers
you may also decide if the performance is good enough or if it needs
hacking.

> I also heard about delegates being 20x slower when invoking and creating
> then creating objects and invoking methods (*). But that was about .NET 1.0 (or

Care to create a little benchmark with the two different ways to do it?
I'm not sure what kind of usage you mean exactly, but creating a
delegate is slightly more time consuming than creating a simple object
and so it a delegate call vs a simple method (interface) call, but the
overhead should be much lower than 20x.
In my tests calls through a delegate are 2-2.5x (for an empty method)
slower than interface calls. I didn't measure delegate creating time,
though: again, you might want to write a benchmark that does what you
want and post it to the list, so we can run it and see if we can make
improvements to the run time.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better



More information about the Mono-devel-list mailing list