[IronPython] The slow part of IronPython

[Michael Foord]

Dino Viehland wrote:
> 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.  

Import performance is something we would desperately like to see 
improved for Resolver One.

Resolver One takes too long to start, and only a small part of that is 
the IronPython startup time - the lions share is in importing Python 
files. IronPython is substantially slower than CPython here.

Resolver One is currently based on IronPython 1, and we are already 
using precompiled modules (one assembly per Python file) - but it does 
little to improve import performance.

Thanks

Michael Foord

> 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.
>
> -----Original Message-----
> 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?
>
> -Dan
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>