[IronPython] The slow part of IronPython
Shri Borde
Shri.Borde at microsoft.com
Thu Jun 26 19:59:08 CEST 2008
Dan, you could try turning on interpretation for all of your scripts. It might hurt your throughput (depending on how compute-intensive your script is), but it would be an interesting exercise to see how much it helps startup. The way to do this on the desktop is to use "ipy.exe -X:Interpret".
Since you are looking at Silverlight, the steps are more complicated. Here are the steps.
Include a C# dll with the following code:
using System;
using Microsoft.Scripting.Runtime;
namespace ScriptingHelpers {
public class ScriptingHelper {
public static LanguageContext GetCurrentLanguageContext(CodeContext context) {
return context.LanguageContext;
}
}
>From your startup Python script, do the following:
# This should be the very first Python file that is executed
import clr
clr.AddReference("ScriptingHelpers.dll")
from ScriptingHelpers import ScriptingHelper
# The DLR will automatically pass in a CodeContext to the function call
currentContext = ScriptingHelper.GetCurrentLanguageContext()
currentContext.Options.InterpretedMode = True
# Now import the rest of the Python scripts.
# These should hopefully load faster since they will be interpreted
import someLargeModule1
import someLargeModule2
-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Wednesday, June 25, 2008 9:11 AM
To: Discussion of IronPython
Subject: Re: [IronPython] The slow part of IronPython
What if I used background threads to import some packages at program
start? I imagine there is a race condition here if the background
thread is still importing module x and the main thread starts to do
the same, but if the worst case is it's parsed/compiled twice, but
imported once, it doesn't matter. The work the background thread does
is free on a multi-core machine.
I may also be able to tweak my code to import some modules at runtime
if they aren't used in the initial startup code path.
IronPython is slow to startup, but really, as Foord pointed out, it's
not noticeable once you start importing.
On Tue, Jun 24, 2008 at 8:22 PM, Dino Viehland
<dinov at exchange.microsoft.com> wrote:
> 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080626/662231e9/attachment.html>
More information about the Ironpython-users
mailing list