On Mon, Aug 25, 2008 at 9:04 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Curt Hagenlocher wrote:
>>
>> It's always irritated me that Python dictionaries don't have the
>> equivalent of TryGetValue.
>
> Like the 'get' method?
Doh!
I don't think that existed in Python 1.5 -- which is the version
Curt Hagenlocher wrote:
On Sun, Aug 24, 2008 at 8:23 AM, Dan Eloff <[EMAIL PROTECTED]> wrote:
A common python optimization is to replace:
if key in dict:
dict[key]
with
try:
dict[key]
except KeyError:
pass
The reasoning is that the try/except method is faster if no exception
is thr
On Sun, Aug 24, 2008 at 8:23 AM, Dan Eloff <[EMAIL PROTECTED]> wrote:
>
> A common python optimization is to replace:
>
> if key in dict:
>dict[key]
>
> with
>
> try:
> dict[key]
> except KeyError:
> pass
>
> The reasoning is that the try/except method is faster if no exception
> is thrown,
On Fri, Aug 15, 2008 at 1:09 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Exceptions (10): 40% slower
I haven't looked at this one yet. I do know that we have a number of
bug fixes for our exception handling which will slow it down though.
I don't consider this to be a high priority though.
Somewhere around 4 weeks from now.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronnie Maor
Sent: Tuesday, August 19, 2008 11:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1
nice!
thanks for **kw fix. that was
ally we now throw a reasonable exception when we don't get a dictionary.
>
> Also making EnvironmentDictionaryStorage not inherit from
> CommonDictionaryStorage. AddNoLock was certainly not doing the right thing
> and this way it's clearer what's going on there.
>
>
>
NoLock was certainly not doing the right thing and
this way it's clearer what's going on there.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, August 15, 2008 11:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython]
nd __ne__ instead of __neq__ we can actually run this
over 2x faster than CPython (on Vista x86 .NET 3.5SP1 on a 2.4ghz Core 2 w/
4gb of RAM).
Cool.
Michael
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Thursday, August 14, 20
defined is horribly slow. With that bug
fixed and using slots and __ne__ instead of __neq__ we can actually run this
over 2x faster than CPython (on Vista x86 .NET 3.5SP1 on a 2.4ghz Core 2 w/
4gb of RAM).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M
IronPython] Performance of IronPython 2 Beta 4 and IronPython 1
Curt Hagenlocher wrote:
> Can you tell us about the environment you're running these tests in?
> Most interesting are the specific OS and the version of mscorwks.dll.
>
It's Win XP SP 3. What's the easiest way of t
Curt Hagenlocher wrote:
Can you tell us about the environment you're running these tests in?
Most interesting are the specific OS and the version of mscorwks.dll.
It's Win XP SP 3. What's the easiest way of telling you the specific
version of mscorwks.dll? I'll get you more details from wor
Can you tell us about the environment you're running these tests in? Most
interesting are the specific OS and the version of mscorwks.dll.
On Thu, Aug 14, 2008 at 9:41 AM, Michael Foord <[EMAIL PROTECTED]>wrote:
> Just for fun I also compared with CPython. The results are interesting,
> I'll tur
ehalf Of Michael Foord
Sent: Thursday, August 14, 2008 9:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1
Just for fun I also compared with CPython. The results are interesting, I'll
turn it into a blog post of course...
2008/8/15 Dino Viehland <[EMAIL PROTECTED]>:
> BTW time.clock() is what I usually use to measure which works on both CPython
> and IronPython. On Ipy we use the .NET Stopwatch class which uses a high
> resolution counter if it's available.
This is what you should do. Python Library Reference sa
Foord
Sent: Thursday, August 14, 2008 9:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1
Just for fun I also compared with CPython. The results are interesting, I'll
turn it into a blog post of course...
Results in milliseco
On Thu, Aug 14, 2008 at 9:41 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Define newstyle (1 000 000):
> IP1: 42047
> IP2: 20484
> Py: 23921
> Define oldstyle (1 000 000): 33% slower
> IP1: 1781
> IP2: 2671
> Py: 2108
We're trying to encourage people to use new-style classes so
Awesome information! I'll start taking a look through all of this and let you
know what I can improve.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Thursday, August 14, 2008 6:15 AM
To: Discussion of IronPython
Subject: [IronPython
Oh - plus it looks like exception handling is about 40% slower in
IronPython 2:
from System import DateTime
class CustomError(Exception):
pass
def test(s):
for i in xrange(10):
try:
raise CustomError('ow')
except CustomError, e:
pass
return (
It looks like I've found the slowdown in our execution framework. It is
caused by extra overhead in the IronPython engine API.
If I created a compiled code object and execute it in a module with
IronPython 1 a million times (code shown below) - it takes 1.5 seconds.
The equivalent (please che
It looks like 2-3 seconds of the 5-6 seconds slowdown in dependency
analysis is due to the way I resolved a weird cyclic import problem (one
that we didn't have in IP1 but due to the spaghetti like imports in that
part of our code I can't reproduce on its own with IP2). I moved an
import into t
20 matches
Mail list logo
