[Patches] [ python-Patches-1629718 ] fast tuple[index] by inlining on BINARY_SUBSCR

[SourceForge.net]

Patches item #1629718, was opened at 2007-01-07 06:51
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1629718&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Hirokazu Yamamoto (ocean-city)
Assigned to: Nobody/Anonymous (nobody)
Summary: fast tuple[index] by inlining on BINARY_SUBSCR

Initial Comment:
Hello.

I noticed there is speed difference between

  a = [0,] # list
  a[0] # fast

and

  a = (0,) # tuple
  a[0] # slow

while solving ICPC puzzle with Python.

I thought this is wierd because, indeed tuple is readonly, there is no conceptual difference between list and tuple when 'extract' item from them.

After investigation, I found this difference comes from the shortcut for list on ceval.c (BINARY_SUBSCR).

Is it valuable to put shortcut for tuple too? I'll attach the patch for release-maint25 branch. Thank you.


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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2007-01-08 07:58

Message:
Logged In: YES 
user_id=1200846
Originator: YES

>see the endless discussions on python-dev...

Thank you, rhettinger. I'm interested in it. I'll see them.

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

Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2007-01-08 06:49

Message:
Logged In: YES 
user_id=1200846
Originator: YES

Sorry, I want to withdraw this.

Python/lib/test/testall.py
===> list: 2541719, tuple: 620815, other: 6174214

The ratio of tuple seems relatively low.
File Added: statistics.patch

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-08 04:56

Message:
Logged In: YES 
user_id=80475
Originator: NO

I recommend against this.

Any additional specialization code will necessarily slow down other cases
handled by PyObject_GetItem.  So, the merits of speeding-up tuple indexing
need to be weighed against the costs (slowing down other code and the
excess loading of ceval.c with specialization code).

Also, I reject the premise that there is no conceptual difference between
list and tuple indexing.  The former is a primary use case for lists and
the latter is only incidental to tuple use cases (see the endless
discussions on python-dev and comp.lang.python about why tuples are not to
be regarded as immutable lists and in fact have a different intended set of
uses).

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

Comment By: Martin v. Löwis (loewis)
Date: 2007-01-07 22:34

Message:
Logged In: YES 
user_id=21627
Originator: NO

It would be helpful to get some statistics on how often this occurs: of
all case of BINARY_SUBSCR, how man refer to tuples, how many to lists, and
how many to other objects?

To get some data, you can measure a run of a test suite, or a run of IDLE,
or of compileall.


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

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