3 ms·
I think you've got that exactly backwards. IronPython is much slower than CPython at exception handling and somewhat slower with strings, but very good at, e.g.
by gjm11 17y ago
I think you've got that exactly backwards. IronPython is much slower than CPython at exception handling and somewhat slower with strings, but very good at, e.g., simple arithmetic operations. (Presumably the JIT turns them into reasonably nice native code.) It's somewhat faster than CPython on PyStone and quite a lot slower on the Richards benchmark. It takes substantially longer to run the whole PyBench suite than CPython, but that's entirely accounted for by its rotten performance with exceptions.
- jules 17y agoInteresting that IronPython is faster than CPython at processing exception handlers when no exception is thrown, but much slower at throwing.
- 0x7feb38ad 17y agoJust goes to show how important it is to bug-free code when developing on the .NET platform. You don't want those exceptions slow down you're code.
- torial 17y agoI remember when FePy was first coming out, and Jim Hugunin was encountering considerable slowness in regard to exceptions, and he conferred with Guido about it because the fail-first idiom is a preferred python strategy. Anyways, Guido was like, you are functionally equivalent so it doesn't matter. (I'm just regurgitating my rough memory of Jim's blog about it.) But that was also the first time I learned how disruptive an exception was to .Net program flow. I've also seen it in general with other .Net languages -- exceptions kill performance, and defensive programming is very worth the extra effort.