3 ms·

Well, it was pretty lopsided, but there were some things that IPy was pretty good at. Exceptions are much more efficient, there were some bright spots in dictio

by itgoon 17y ago

Well, it was pretty lopsided, but there were some things that IPy was pretty good at. Exceptions are much more efficient, there were some bright spots in dictionary and string manipulation. Given that CPython is about Python, whereas IronPython is about Python and the MS environment (libraries, IIS, MSSQL, etc.), it looks like a decent alternative if you like Python, or are just tired of C#.

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 ago
  Interesting that IronPython is faster than CPython at processing exception handlers when no exception is thrown, but much slower at throwing.
  - 0x7feb38ad 17y ago
    Just 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 ago
    I 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.

by itgoon 17y ago

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 ago
Interesting that IronPython is faster than CPython at processing exception handlers when no exception is thrown, but much slower at throwing.
- 0x7feb38ad 17y ago
  Just 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 ago
  I 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.