Martin v. Löwis wrote:
I'm talking about IronPython on the Microsoft .NET framework - although it is likely that the same is true of IronPython on Mono.
I see. It would be interesting to find out why this is so much slower - I cannot believe that it is inherent in the commercial .NET framework, but rather expect that it is some issue in IronPython (*). Also, the test case measured doesn't entirely reflect what is proposed, since it catches the exception in the same function - for a realistic comparison, the raise should occur in a function call (so to measure the overhead of stack unwinding also).
Regards, Martin
(*) My wild guess is that IronPython feels obliged to provide traceback objects, and that this a costly operation - I just can't believe that exceptions are themselves costly on .NET, in the Microsoft implementation. In the specific case, it would be possible to suppress traceback generation.
I have discussed this issue with the IronPython team several times. They say that it is a deliberate design decision in .NET - to minimize the cost of exception handling code in the absence of exceptions at the expense of slower performance when exceptions are raised. Googling for ".NET exceptions performance" would seem to confirm that. Apparently this article on the managed exception model was written by one of the core developers: http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx "This is light years away from returning a -1 from your function call. Exceptions are inherently non-local, and if there’s an obvious and enduring trend for today’s architectures, it’s that you must remain local for good performance. Relative to straight-line local execution, exception performance will keep getting worse. Sure, we might dig into our current behavior and speed it up a little. But the trend will relentlessly make exceptions perform worse. How do I reconcile the trend to worse performance with our recommendation that managed code should use exceptions to communicate errors? By ensuring that error cases are exceedingly rare. We used to say that exceptions should be used for exceptional cases, but folks pushed back on that as tautological." Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog