[IronPython] The slow part of IronPython
dinov at exchange.microsoft.com
Tue Jun 24 17:28:11 PDT 2008
There's a couple of plans a foot. We have been working on a pre-compilation feature like .pyc for IronPython 2.0 It's actually in Beta 3 but unfortunately it doesn't quite work yet which is the reason we haven't said anything. It will be there (and working!) in beta 4. That's the short term solution but unfortunately it won't really work with Silverlight - there's no way to compile against the Silverlight mscorlib from the desktop CLR and Silverlight doesn't support saving assemblies to disk.
Another option which generally reduces compilation cost, but still not enough, is to use the -X:LightweightScopes command line option. But again that's not available in Silverlight :(. We may switch to using this mode by default at some point in the future but it needs a little more tuning - right now there's a noticeable difference between throughput perf in the two modes.
Longer term we'd like to leverage the interpreter mode. This would result in importing a module initially just bringing up the Python AST for the module and then interpreting that until methods start getting called frequently. The bulk of the import time is going to compilation so doing this would fix a huge amount of the problem. Unfortunately we probably won't get to that for IronPython 2.0 as we're mostly focused on a few final DLR changes and then lots of bug fixing.
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Tuesday, June 24, 2008 4:57 PM
To: Discussion of IronPython
Subject: [IronPython] The slow part of IronPython
In my experience IronPython 2 is fast, I find it to be 3x CPython for
some common tasks like serialization.
But one area where it still lags way behind is module importing. I've
noticed module importing to be an order of magnitude, over 20x, slower
in most cases.
I've got to think that if it's so expensive to import modules,
following the CPython approach of caching generated code in .pyc files
makes a lot of sense. I notice with Silverlight that when a project
gets large enough, the module importing actually takes more time than
network transfer! I'm seriously considering preloading modules in
background threads to save time on multi core/processor machines.
Are there any plans afoot to address this?
Users mailing list
Users at lists.ironpython.com
More information about the Users