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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
<[EMAIL PROTECTED]> 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: [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
>
_______________________________________________
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
