[Patches] [ python-Patches-552433 ] Looping Optimization
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 07 May 2002 11:01:00 -0700
Patches item #552433, was opened at 2002-05-05 05:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470
Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Martin v. Löwis (loewis)
Summary: Looping Optimization
Initial Comment:
Optimized the inner loop for iterobjects resulting in
a 19% speed-up for tuples and a 15% improvement for
strings and xrange objects. Dictionaries and lists
are unaffected (already handled as a special case or
with their own iterators).
1. Replaced PyList_Check with PyList_CheckExact.
Loses the special case handling for list subtypes but
gains speed because PyList_Check called the slow
function, PyType_IsSubtype.
2. Added special case handling for tuples. Identical
to the existing special case for lists (calls ob_size
and ob->item[i] directly).
3. Replaced the call to PySequence_GetItem function
with a macro for direct access to the sequence's
sq_item slot. Saves a function call, unnecessary
(previously checked) checks for tp_as_sequence and
sq_item, and an unnecessary check for negative indices
(sq_item has its own checks).
This small patch speeds-up looping throughout Python
whether it is called through list(seq), a for-loop, or
a functional.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-06 19:29
Message:
Logged In: YES
user_id=80475
Agreed. Replaced assertion with BadInternalCall.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-05-06 18:56
Message:
Logged In: YES
user_id=21627
I'm not sure what the convention for assertions is; the
alternative is to raise BadInternalCall.
If I would have to define a convention, it would go like
this: If this can be called incorrectly by extension
modules, it's a bad internal call; if the only callers would
be the core, it's an assert. It is also an assert if you can
prove that it can never occur with the current code base.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-06 18:27
Message:
Logged In: YES
user_id=80475
Done.
Added news and docs.
Instead of raising an exception, converted PySequence_Check
to an assertion because it is a pre-condition of the
function and has already been checked by PyObject_GetIter.
The only way for the assertion to fail is if an extension
writer by-passes _GetIter and directly calls PySeqIter_New
with a non-sequence argument.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-05-06 10:42
Message:
Logged In: YES
user_id=21627
The patch looks good, but needs some minor corrections:
Returning NULL in response to a failed _Check is incorrect -
no exception is set at that point.
I think the addition of PySequence_ITEM needs to be
mentioned in the documentation and Misc/NEWS.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470