lease and all of the sign off work that entails. We haven't ruled it out
>> but we sure would like to avoid it if possible.
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil
>> Dworakowski
>> Sent
OTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil
> Dworakowski
> Sent: Monday, October 13, 2008 9:42 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] parallel importing
>
> Could you provide a patch?
>
> On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland <[EMAI
of IronPython
Subject: Re: [IronPython] parallel importing
Could you provide a patch?
On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Making the code changes is easy - the hard part is really doing a new 1.x
> release and all of the sign off work that
Yep, give me a bit of time - I'll try and get it later today or tomorrow...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil Dworakowski
Sent: Monday, October 13, 2008 9:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] parallel impo
ution to this in the past has been ngen
hence the reason we're leveraging that for the short term.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vernon Cole
Sent: Monday, October 13, 2008 9:58 AM
To: Discussion of IronPython
Subject: Re: [IronPython] parallel importing
Help
Curt Hagenlocher wrote:
The" .NET people" might say they already have an answer which involves
precompiling the IL with NGEN. And in fact, using DLR precompilation
and NGEN with IronPython results in some pretty nice performance
improvements.
But using IronPython directly against .py files i
The" .NET people" might say they already have an answer which involves
precompiling the IL with NGEN. And in fact, using DLR precompilation and
NGEN with IronPython results in some pretty nice performance improvements.
But using IronPython directly against .py files incurs several expenses that
ar
On Mon, Oct 13, 2008 at 11:57 AM, Vernon Cole <[EMAIL PROTECTED]> wrote:
> Help me out here. I have seen many references to schemes to optimize import
> speeds on Iron Python. Isn't this an attempt to make up for the snail-like
> startup speeds suffered by all .net applications?
.NET has a substa
Help me out here. I have seen many references to schemes to optimize import
speeds on Iron Python. Isn't this an attempt to make up for the snail-like
startup speeds suffered by *all* .net applications? It seems to me that when
Iron Python finally starts running, it imports and performs very well.
like to avoid it if possible.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil
> Dworakowski
> Sent: Monday, October 13, 2008 9:07 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] parallel importing
>
> W
Kamil Dworakowski
Sent: Monday, October 13, 2008 9:07 AM
To: Discussion of IronPython
Subject: Re: [IronPython] parallel importing
Would that be easy to backport fix for #2 to 1.x branch?
On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> This is all still on 1
Would that be easy to backport fix for #2 to 1.x branch?
On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are
> locking but on the wrong object in 1.x).
>
> #2 is still broken in 2.x though as well.
This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are
locking but on the wrong object in 1.x).
#2 is still broken in 2.x though as well.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil Dworakowski
Sent: Monday, October 13, 2008
I hope that these issues can be resolved, importing time really needs
to be reduced in any complex IronPython application, and this looks
like the best hope yet for doing that.
-Dan
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpytho
14 matches
Mail list logo
