tags:

views:

137

answers:

5

It seems that IronPython 2.0.1 executes a script file about 3x slower than IronPython 1.x. I'm not convinced that it isn't something I'm doing so I'm wondering if others have had a similar experience.

I have a 200k python script that takes 5 seconds to execute from a file on IP 1.x and nearly 18 seconds in IP 2.0.1!

A: 

Might be worth running through a profiler to see where the bottle necks are?

Kev
A: 

There are definitely some things that are much slower in IronPython than they are in Python. Often this is because you're hitting a weird corner case in the implementation. It's worth trying to reduce it down to a very simple script that exhibits the performance difference and sending that to the IronPython mailing list - the devs are very responsive.

There's been a series of interesting blog posts about IronPython performance recently - this is a good overview. The summary is that you can get very good performance, once you avoid the pitfalls, and the IP team are very interested in finding out about these problems and fixing them quickly. Narrowing down a repro to find the pitfall is the hardest part - once you've worked out what triggers the behaviour it's generally easy to work around.

wilberforce
Thanks, actually I'm talking about a seemingly large perf difference between IronPython 1 (pre-dlr) and IronPython 2. not CPython and IronPython. Having said that, the performance overview of Python,IP and Jython was very informative. Thanks.
logan
Ah, right. Actually, everything I've said holds true for isolating performance regressions from IP 1 to IP 2 - for example, a lot of the work in porting Resolver One to IP 2 was finding this kind of problem and working with the dev team to diagnose the cause.
wilberforce
We definitely saw odd performance degradations (going from 1 to 2) in places where it seemed like what we were doing couldn't be related to the problem, which actually turned out to be things like method dispatch caches overflowing. Many of them seemed to be consequences of the architectural changes in extracting the DLR, and optimisation techniques. Dino and the team were very helpful in working out what was happening.
wilberforce
A: 

I also had a similar issue when I started using IronPython 2.0. The problem for me was the dismal startup time for the DLR. Once the runtime is loaded the script performance is reasonably fast.

To reduce the runtime startup time, you can try NGEN'ing the binaries. This reduced the startup time around 60% for me.

Even with this fix, it is still not that fast relatively speaking. If your script is not doing much the startup will still take a significant portion of the overall time. Hopefully the DLR team will fix the startup performance issues soon.

DSO
Note, I suspect that DLR startup time is not as much of an issue in embedded scenarios where the runtime is loaded once and re-used. If your solution allows it, you can try hosting the runtime and launch scripts from it.
DSO
I am hosting the runtime inside a C# app. The bottleneck is when I call execute. Once the code is initially parsed..the performance is acceptable.
logan
As it turns out...startup time is a problem in embedded scenarios as well. I upgraded to 2.6B1 and my problem was fixed.
logan
A: 

Hi Logan,

Does your timings include startup time? IronPython 2.6 Beta has radical improvements to startup time and code compilation/execution. Suggest you try that release if you can.

Cheers, Davy

daftspaniel
2.0.1 startup time was the issue. Thank you very much. I hope that the beta tag doesn't scare "management" lol.
logan
A: 

You can read the article IronPython: Reusing Import Symbols to Avoid Performance Hits that can make the embedded scenarios run faster.

Caglar Toklu