[Python-Dev] PEP 377 - allow __enter__() methods to skip the statement body

[Michael Foord]

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