This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: On the update_slot() behavior
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, naofumi-h
Priority: high Keywords: patch

Created on 2002-02-08 04:49 by naofumi-h, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
slot.dif naofumi-h, 2002-02-08 04:49
slot-1.dif naofumi-h, 2002-03-12 02:49
Messages (7)
msg38894 - (view) Author: Naofumi Honda (naofumi-h) Date: 2002-02-08 04:49
Inherited method __getitem__ of list type
in the new subclass is unexpectedly slow. 

For example,

x = list([1,2,3])
r = xrange(1, 1000000)
for i in r:
        x[1] = 2

==> excution time: real    0m2.390s 

class nlist(list):
        pass

x = nlist([1,2,3])
r = xrange(1, 1000000)
for i in r:
        x[1] = 2

==> excution time: real    0m7.040s
about 3times slower!!!

The reason is:
for the __getitem__ attribute, there are
two slotdefs in typeobject.c
(one for the mapping type, and
the other for the sequence type).

In the creation of new_type of list type, 
fixup_slot_dispatchers() and update_slot() functions
in typeobject.c allocate the functions
to both sq_item and mp_subscript slots
(the mp_subscript slot had originally no function,
  because the list type is a sequence type),
 and it's an unexpected allocation for the mapping
 slot since the descriptor type of __getitem__
 is now WrapperType for the sequence operations.

If you will trace x[1] using gdb,
you will find that in PyObject_GetItem() 
m->mp_subscript = slot_mp_subscript 
is called instead of a sequece operation
because mp_subscript slot was allocated by
fixup_slot_dispatchers().
In the slot_mp_subscirpt(),
call_method(self, "__getitem__", ...) is invoked,
and turn out to call a wrapper descriptors for
the sq_item.

As a result, the method of list type finally called,
but it needs many unexpected function calls.

I will fix the behavior of fixup_slot_dispachers()
and update_slot() as follows:

Only the case where 
*) two or more slotdefs have the same attribute
   name where at most one corresponding slot
   has a non null pointer
*) the descriptor type of the attribute is
   WrapperType,

these functions will allocate the only one
function to the apropriate slot.

The other case, the behavior not changed
to keep compatiblity!
(in particular, considering the case where
  user override methods exist!)

The following patch also includes speed up routines
to find the slotdef duplications,
but it's not essential!
msg38895 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-03-10 22:14
Logged In: YES 
user_id=6380

Thanks for the analysis! Would you mind submitting a new
patch without the #ifdef ORIGINAL_CODE stuff? Just
delete/replace old code as needed -- cvs diff will show me
the original code. The ORIGINAL_CODE stuff makes it harder
for me to get the point of the diff. Also, maybe you could
leave the speedup code out, to show the absolutely minimal
amount of code needed.
msg38896 - (view) Author: Naofumi Honda (naofumi-h) Date: 2002-03-12 02:49
Logged In: YES 
user_id=452575

I will post a new patch containing a essential part of
previous one (i.e. without ifdef and almost all speed up
routines).
msg38897 - (view) Author: Naofumi Honda (naofumi-h) Date: 2002-03-12 02:49
Logged In: YES 
user_id=452575

I will post a new patch containing a essential part of
previous one (i.e. without ifdef and almost all speed up
routines).
msg38898 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-03-23 03:47
Logged In: YES 
user_id=6380

Is slot-1.dif the promised new patch?
msg38899 - (view) Author: Naofumi Honda (naofumi-h) Date: 2002-03-23 08:40
Logged In: YES 
user_id=452575

Yes. slot-1.dif is a new version.
At least, I purged ifdef ... as you want.
msg38900 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-04-04 23:45
Logged In: YES 
user_id=6380

Thanks!  Checked in, with much refactoring.
History
Date User Action Args
2022-04-10 16:04:57adminsetgithub: 36049
2002-02-08 04:49:49naofumi-hcreate