[Python-Dev] 2.5a2 try/except slow-down: Convert to type?
We're working at the sprint on tracking this down. I want to provide some
history first and then what we're looking for feedback on.
Steve Holden found this on Sunday, the pybench try/except test shows a ~60%
slowdown from 2.4.3 to 2.5a2. The original test is, roughly:
for i in range(N):
try: raise ValueError, 'something'
except: pass
But changing it to the following shows 0% slowdown from 2.4.3 to 2.5a2:
e = ValueError('something')
for i in range(N):
try: raise e
except: pass
The change is that from 2.4.3 to 2.5a2 includes Brett Cannon's patch to make
exceptions all new-style objects.
Brett provided the following direction:
>Right, I meant change how it (BaseException) is written. Right now
>it uses PyMethodDef for magic methods and just uses PyType_New()
>as a constructor. I was wondering if, for some reason, it would be
>faster if you used a PyType_Type definition for BaseException and
>used the proper C struct to associate the methods with the class.
Richard Jones has done some investigation, and we're looking at fixing
it from the current implementation. This is basically a direct
implementation of the old-style exception, but inheriting from object.
Converting it to a type in C should reduce the cost dramatically.
We're looking for feedback on where this may cause problems or break
things. Thoughts?
Thanks,
Sean
--
Thieves broke into Scotland Yard yesterday and stole all the toilets.
Detectives say they have nothing to go on.
Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a2 try/except slow-down: Convert to type?
Sean Reifschneider <[EMAIL PROTECTED]> writes:
> We're working at the sprint on tracking this down. I want to provide some
> history first and then what we're looking for feedback on.
>
> Steve Holden found this on Sunday, the pybench try/except test shows a ~60%
> slowdown from 2.4.3 to 2.5a2. The original test is, roughly:
>
>for i in range(N):
> try: raise ValueError, 'something'
> except: pass
>
> But changing it to the following shows 0% slowdown from 2.4.3 to 2.5a2:
>
>e = ValueError('something')
>for i in range(N):
> try: raise e
> except: pass
>
> The change is that from 2.4.3 to 2.5a2 includes Brett Cannon's patch to make
> exceptions all new-style objects.
Could it just be that instantiating instances of new-style classes is
slower than instantiating instances of old-style classes? There's not
anything in what you've posted to suggest that exceptions are involved
directly.
Cheers,
mwh
--
Get out your salt shakers folks, this one's going to take more
than one grain. -- Ator in an Ars Technica news item
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a2 try/except slow-down: Convert to type?
Michael Hudson wrote: > Could it just be that instantiating instances of new-style classes is > slower than instantiating instances of old-style classes? There's not > anything in what you've posted to suggest that exceptions are involved > directly. python -mtimeit -s "class Exception(object): pass" "Exception()" 100 loops, best of 3: 0.284 usec per loop python -mtimeit -s "class Exception: pass" "Exception()" 100 loops, best of 3: 0.388 usec per loop python -mtimeit "Exception()" 100 loops, best of 3: 1.95 usec per loop ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a2 try/except slow-down: Convert to type?
Fredrik Lundh wrote: >> Could it just be that instantiating instances of new-style classes is >> slower than instantiating instances of old-style classes? There's not >> anything in what you've posted to suggest that exceptions are involved >> directly. for completeness, here's the corresponding results from 2.4: python -mtimeit -s "class Exception(object): pass" "Exception()" 100 loops, best of 3: 0.278 usec per loop python -mtimeit -s "class Exception: pass" "Exception()" 100 loops, best of 3: 0.387 usec per loop python -mtimeit "Exception()" 100 loops, best of 3: 0.989 usec per loop > python -mtimeit -s "class Exception(object): pass" "Exception()" > 100 loops, best of 3: 0.284 usec per loop > > python -mtimeit -s "class Exception: pass" "Exception()" > 100 loops, best of 3: 0.388 usec per loop > > python -mtimeit "Exception()" > 100 loops, best of 3: 1.95 usec per loop ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a2 try/except slow-down: Convert to type?
On Wed, May 24, 2006 at 11:36:52AM +0100, Michael Hudson wrote: >Could it just be that instantiating instances of new-style classes is >slower than instantiating instances of old-style classes? There's not >anything in what you've posted to suggest that exceptions are involved >directly. Sorry, I should have mentioned that. Yes, instantiating new-style classes is slower than old-style, but only by about 10%. The slow-down for try/except is more like 60%. So, it's not just the new versus old difference. It's much, much more than that. Thanks, Sean -- The Law of Software Development and Envelopment at MIT: Every program in development at MIT expands until it can read mail. Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySequence_Fast_GET_ITEM in string join
On 5/23/06, Andrew Dalke <[EMAIL PROTECTED]> wrote: > Me [Andrew Dalke] said: > > The relevant code in stringobject uses PySequence_Fast_GET_ITEM(seq, > > i), > > which likely doesn't know about my derived __getitem__. > > Oops, I didn't know what the code was doing well enough. The > relevant problem is > > seq = PySequence_Fast(orig, ""); > > That calls __iter__ on my derived list object, which knows nothing > about my overridden __getitem__ Put another way, the problem is related to your initial claim: > I can derive from list and override __getitem__ You can do that, but you should not. It's almost a bug that you can. Jeremy > > So things are working as designed. > > Well, back to blundering about. Too much brennivin. ;) > > Andrew > [EMAIL PROTECTED] > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] replace on empty strings
so, which one is correct ?
Python 2.4.3
>>> "".replace("", "a")
''
>>> u"".replace(u"", u"a")
u'a'
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5a2 try/except slow-down: Convert to type?
We've done some more research on it, and Richard Jones is working on it right now. We'll see how it works, probably tomorrow. Thanks, Sean -- If you don't have time to do it right, when will you ever find time to do it over? Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] replace on empty strings
On 5/24/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> so, which one is correct ?
>
> Python 2.4.3
> >>> "".replace("", "a")
> ''
> >>> u"".replace(u"", u"a")
> u'a'
Since 'x'.replace('', 'a') and u'x'.replace('', u'a') return 'axa' and
u'axa', respectively, I conclude that the unicode version is correct
and the 8-bit string version is an anomaly.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Web-SIG] Adding wsgiref to stdlib
Ian Bicking wrote: > Phillip J. Eby wrote: > >>At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote: >> >>>I'd like to include paste.lint with that as well (as wsgiref.lint or >>>whatever). Since the last discussion I enumerated in the docstring all >>>the checks it does. There's still some outstanding issues, mostly where >>>I'm not sure if it is too restrictive (marked with @@ in the source). >>>It's at: >>> >>> http://svn.pythonpaste.org/Paste/trunk/paste/lint.py >> >>Ian, I see this is under the MIT license. Do you also have a PSF >>contributor agreement (to license under AFL/ASF)? If not, can you place >>a copy of this under a compatible license so that I can add this to the >>version of wsgiref that gets checked into the stdlib? > > > I don't have a contributor agreement. I can change the license in > place, or sign an agreement, or whatever; someone should just tell me > what to do. I faxed in a contributor aggreement, and added this to the comment header of the file: # Also licenced under the Apache License, 2.0: http://opensource.org/licenses/apache2.0.php # Licensed to PSF under a Contributor Agreement ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] replace on empty strings
Fredrik Lundh wrote:
> so, which one is correct ?
>
> Python 2.4.3
> >>> "".replace("", "a")
> ''
> >>> u"".replace(u"", u"a")
> u'a'
Probably there shouldn't be any "correct" in this case,
i.e. the result of replacing an empty string should be
undefined (because any string contains infinitely many
empty substrings).
+0 on raising an exception if you try.
--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] replace on empty strings
[/F]
>> so, which one is correct ?
>>
>> Python 2.4.3
>> >>> "".replace("", "a")
>> ''
>> >>> u"".replace(u"", u"a")
>> u'a'
[Greg Ewing]
> Probably there shouldn't be any "correct" in this case,
> i.e. the result of replacing an empty string should be
> undefined (because any string contains infinitely many
> empty substrings).
Where are they? For a string s, I count s[0:0], s[1:1], ...,
s[len(s):len(s)], or len(s)+1 empty substrings in all.
While str and unicode `replace` currently disagree about that when
len(s)==0, they agree when len(s)>0:
>>> " ".replace("", "A")
'A A'
>>> u" ".replace("", "A")
u'A A'
> +0 on raising an exception if you try.
I'd be +1, except the idea that there are len(s)+1 empty substrings in
a string is pretty much ubiquitous:
>>> "" in ""
True
>>> u"" in u""
True
>>> "".index("")
0
>>> u"".index(u"")
0
>>> " ".rindex("")
1
>>> u" ".rindex(u"")
1
>>> "".count("")
1
>>> u"".count(u"")
1
>>> " ".count("")
2
>>> u" ".count(u"")
2
So the current str.replace really is an oddball.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] replace on empty strings
On 5/24/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > so, which one is correct ?
> >
> > Python 2.4.3
> > >>> "".replace("", "a")
> > ''
> > >>> u"".replace(u"", u"a")
> > u'a'
>
> Probably there shouldn't be any "correct" in this case,
> i.e. the result of replacing an empty string should be
> undefined (because any string contains infinitely many
> empty substrings).
No. That's what older versions of Python did, and it was changed to
the current behavior, except someone screwed up the edge case for
8-bit strings.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Socket regression
I'd like to point out sf bug #1494314 ( http://sourceforge.net/tracker/index.php?func=detail&aid=1494314&group_id=5470&atid=105470 ) as an important one to fix before 2.5. It's clearly a regression and the fix should be simple (there's a patch on the ticket). Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
