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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
