[Patches] [ python-Patches-517521 ] Optimization for PyObject_Get/SetAttr

noreply@sourceforge.net noreply@sourceforge.net
Fri, 15 Mar 2002 05:41:06 -0800


Patches item #517521, was opened at 2002-02-14 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517521&group_id=5470

Category: Core (C code)
Group: Python 2.2.x
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optimization for PyObject_Get/SetAttr

Initial Comment:
The attached patch is based on the assumption that the 
vast majority of calls to PyObject_GetAttr and 
PyObject_SetAttr use a PyString (rather than a 
PyUnicode) as the name parameter.  Because these 
routines perform a PyUnicode_Check first, every call 
(with a PyString as name) requires a call to 
PyType_IsSubType.  By reorganizing so that 
PyString_Check is called first, the call to 
PyType_IsSubType is avoided in the common case.  The 
same reorganization is done for 
PyObject_GenericGet/SetAttr.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 14:41

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as object.c 2.164.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 09:31

Message:
Logged In: YES 
user_id=31435

+1 on integrating the patch.  Better 2% today than 200% 
that may never materialize!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 09:19

Message:
Logged In: YES 
user_id=21627

It is a fairly trivial change, and it has no ill effects, so
I think this it is worth the trouble (in particular since a
duplicate has been submitted as 529768).

Whether PEP 263 affects it depends on the implementation
strategy taken in phase 2; most likely, attribute accesses
remain as byte strings (it is already decided that they
remain restricted to ASCII).

Unless there are any strong objections to this patch, I'd
like to integrate it.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-03-15 08:18

Message:
Logged In: YES 
user_id=250749

I've tried this patch and it appears to have no ill affects 
on a FreeBSD 4.4 system, though I haven't exhaustively 
checked it.

My testing (using pystone.py and PyBench 1.0) shows only 
about 2% gain, which in isolation is hardly worth the 
bother (though a number of 2% gains can cumulatively be 
attactive).

I don't know at this point whether PEP 263 (if accepted) 
would have any affect on the change implemented by the 
patch; if so, it may not be worth pursuing.


----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-03-15 08:18

Message:
Logged In: YES 
user_id=250749

I've tried this patch and it appears to have no ill affects 
on a FreeBSD 4.4 system, though I haven't exhaustively 
checked it.

My testing (using pystone.py and PyBench 1.0) shows only 
about 2% gain, which in isolation is hardly worth the 
bother (though a number of 2% gains can cumulatively be 
attactive).

I don't know at this point whether PEP 263 (if accepted) 
would have any affect on the change implemented by the 
patch; if so, it may not be worth pursuing.


----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-03-15 08:16

Message:
Logged In: YES 
user_id=250749

I've tried this patch and it appears to have no ill affects 
on a FreeBSD 4.4 system, though I haven't exhaustively 
checked it.

My testing (using pystone.py and PyBench 1.0) shows only 
about 2% gain, which in isolation is hardly worth the 
bother (though a number of 2% gains can cumulatively be 
attactive).

I don't know at this point whether PEP 263 (if accepted) 
would have any affect on the change implemented by the 
patch; if so, it may not be worth pursuing.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517521&group_id=5470