[Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up
SourceForge.net
noreply at sourceforge.net
Mon Feb 28 00:56:23 CET 2005
Patches item #1153056, was opened at 2005-02-27 21:14
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyXxx_Check() speed-up
Initial Comment:
Once upon a time, the macros PyInt_Check(),
PyString_Check(), etc., used to be very fast: just a
pointer comparison. But 2.2 came. Suddenly, types
could inherit from each other. Thus the macros became:
(ob->type == &PyXxx_Check ||
PyType_IsSubType(ob->type, &PyXxx_Check)
Subtyping of built-in types still being rare, the
common cases here are: (1) ob is indeed exactly of type
Xxx, (2) ob is absolutely not an instance of Xxx. The
macro is fast for case 1 but becomes a call to a slow
function in case 2.
It sounds minor -- but a program can make half a
million "case 2" calls in 5 seconds.
The following patch proposes to fix that, based on a few
measurements that show which are the more common
"case 2" calls in a few applications. It adds a
family of type flags meaning "this type is not at all an
Xxx", for Xxx in [module, tuple, float, int, unicode,
long, complex, str].
I cannot measure the performance gain on this machine
(figures vary all the time) but it looks like some 0.2s
for the above-mentioned 5s program.
----------------------------------------------------------------------
>Comment By: Armin Rigo (arigo)
Date: 2005-02-27 23:56
Message:
Logged In: YES
user_id=4771
I'm not sure I understand your suggestion. Would each type
have an array of N bits, where N is the total number of types
that exist? That looks quite unreasonable in any program
that builds a lot of types (I know some that build them
programatically in loops). What I did is a limited
version of that: a bitfield with room for only some commonly
checked-for superclasses.
(With some care, my patch could be modified to build the
bitfield in PyType_Ready(); this would allow the
PyXxx_Check() macros to become a single bit check operation.)
Changing the base classes isn't an issue in my limited patch
because you cannot ever add or remove the core built-in types
I check for from the bases of an existing type.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-02-27 23:44
Message:
Logged In: YES
user_id=21627
I would rather see a constant-time subtype check implemented
in Python, using strategies that other interpreters have
been using for a long time.
Essentially, each type gets a unique number (e.g. in the
order of PyType_Ready calls), and a bit-field of all
supertypes, with a bit set for each type that is one of its
supertypes. Creation of the bitfield could be delayed until
a subtype check is actually needed.
The tricky part is to update the supertype bitmask when
__super__ is assigned.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470
More information about the Patches
mailing list