> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4