[IronPython] The slow part of IronPython

[Dino Viehland]

Well IsolatedStorage probably isn't good enough.  The problem is we actually save a real .NET assembly to disk and do so using reflection - which is the only way this offers any benefits - the slow part is generally compilation.  So Reflection.Emit would have to support IsolatedStorage for this to work.

If you really wanted to use it out of Silverlight you could probably save it to disk on the desktop CLR, ildasm it, edit it, update the references to the Silverlight assemblies, and then ilasm it (or programmatically w/ something like Cecil I suppose).  But we'd never actually support that or advise you do it :)

You'll also want to measure the benefit you get w/ your code before you even try - the speed improvement of pre-compilation can be less significant than you'd really like.  The best improvements come when you can compile multiple modules into a single file.  But compiling one module per file ends up not being much of a gain.  It's also not free - it has the same performance cost as the lightweight scopes I mentioned before.  And there's still a lot of code gen for user-defined types and call sites.

The good news, I suppose, is startup is now our own biggest performance concern - working set's at the top of the list as well.  Throughput is largely higher across the board in 2.0 except for in some crazy dynamic scenarios.  So it's definitely where our performance work will focus on in the future and we also have a few more ideas to consider as well.  Likely it'll be a combination of many things that ultimately speeds this up.  Sorry it won't get immediately better - I'm as unhappy about it as you :(.

-----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 5:58 PM
To: Discussion of IronPython
Subject: Re: [IronPython] The slow part of IronPython

> 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.

Wow, looking forward to that!

>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.

That seems more like a Silverlight problem than an IronPython one.
However, I can in Silverlight save arbitrary data to IsolatedStorage
(client side). This would, I think, enable caching the compiled
modules and loading them again on a per user basis, if only I have the
right api in IronPython to get the compiled module as byte
array/string and load from the same. I could then tweak the importing
machinery (import hook? it can be done in CPython) slightly to check
IsolatedStorage first for the compiled module and load that if
possible, falling back to the standard importing mechanism, with the
minor difference of saving the compiled module to IsolatedStorage.
i.e. build in the .pyc saving/loading in python using IsolatedStorage
instead of the file system.

Any chance you guys could provide that api? Because it would be a
dream to see IronPython totally scream in the browser.

-Dan
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com