You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
isinstance is 4x as slow as in 2.5 because the common case raises #46556
isinst.diff: Patch to short circuit an exact match
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/gvanrossum'closed_at=<Date2008-07-13.18:38:06.819>created_at=<Date2008-03-16.15:45:41.157>labels= ['interpreter-core', 'performance']
title='isinstance is 4x as slow as in 2.5 because the common case raises'updated_at=<Date2008-07-13.18:38:06.813>user='https://bugs.python.org/jyasskin'
r58099 added an exception to the common case of PyObject_IsInstance(),
when the class has no __instancecheck__ attribute. This makes
isinstance(3, int) take 4x as long as in python 2.5.
I'll set this to critical to ensure that I look at it at least once
before we release. I'm not sure however that we can do much about it --
nor that it matters much in practice.
Perhaps we could speed up certain common isinstance() calls by skipping
the lookup for non-heap types; I believe those never override
__instancheck__.
Perhaps, though I'm not sure if that doesn't slow things down further
due to the complicated protocol for calling it. Also, there's a
recursion check in the built-in implementation.
No doubt it would take some work. IMO, code for a slot is worth it;
otherwise, many apps will have to pay the price for ABCs even if they
don't use the feature. For my company, that would deter an upgrade to 2.6.
% ./python.exe -mtimeit 'isinstance(3, int)'
1000000 loops, best of 3: 0.269 usec per loop
% ../release25-maint/python.exe -mtimeit 'isinstance(3, int)'1000000
loops, best of 3: 0.335 usec per loop
So I'd say its no longer 4x slower these days.
Looking at the Object/abstract.c it appears the fix to this has already
been checked in. PyObject_IsInstance already has this in it:
/* Quick test for an exact match */
if (Py_TYPE(inst) == (PyTypeObject *)cls)
return 1;
Activity
jyasskin commentedon Mar 16, 2008
r58099 added an exception to the common case of PyObject_IsInstance(),
when the class has no __instancecheck__ attribute. This makes
isinstance(3, int) take 4x as long as in python 2.5.
gvanrossum commentedon Mar 18, 2008
I'll set this to critical to ensure that I look at it at least once
before we release. I'm not sure however that we can do much about it --
nor that it matters much in practice.
Perhaps we could speed up certain common isinstance() calls by skipping
the lookup for non-heap types; I believe those never override
__instancheck__.
theller commentedon Mar 18, 2008
Would it help to implement a default __instancecheck__ and
__subclasscheck__ for object (or for type), that subclasses can override?
gvanrossum commentedon Mar 18, 2008
Perhaps, though I'm not sure if that doesn't slow things down further
due to the complicated protocol for calling it. Also, there's a
recursion check in the built-in implementation.
rhettinger commentedon Mar 18, 2008
The attribute lookup cost can mostly be eliminated if __instancecheck__
were given a tp slot.
gvanrossum commentedon Mar 18, 2008
Yeah, but tp_ slots are expensive themselves (mostly in the amount of
code that needs to be changed -- see typeobject.c).
rhettinger commentedon Mar 18, 2008
No doubt it would take some work. IMO, code for a slot is worth it;
otherwise, many apps will have to pay the price for ABCs even if they
don't use the feature. For my company, that would deter an upgrade to 2.6.
rhettinger commentedon Mar 18, 2008
Attaching a small patch to speed-up one easy case.
theller commentedon Apr 2, 2008
Issue bpo-2534 has a patch which speeds up isinstance and issubclass by
implementing type.__instancecheck__ and type.__subclasscheck__.
gvanrossum commentedon Jul 9, 2008
Does anyone care about this still?
I added some comments on
http://codereview.appspot.com/504
gpshead commentedon Jul 13, 2008
% ./python.exe -mtimeit 'isinstance(3, int)'
1000000 loops, best of 3: 0.269 usec per loop
% ../release25-maint/python.exe -mtimeit 'isinstance(3, int)'1000000
loops, best of 3: 0.335 usec per loop
So I'd say its no longer 4x slower these days.
Looking at the Object/abstract.c it appears the fix to this has already
been checked in. PyObject_IsInstance already has this in it:
closing.