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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
