fast tuple[index] by inlining on BINARY_SUBSCR

[ocean-city]

BPO	1629718
Nosy	@loewis, @rhettinger
Files	fast tuple[i].patch statistics.patch

^{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 = None
closed_at = <Date 2007-01-08.06:58:11.000>
created_at = <Date 2007-01-07.05:51:17.000>
labels = ['interpreter-core']
title = 'fast tuple[index] by inlining on BINARY_SUBSCR'
updated_at = <Date 2007-01-08.06:58:11.000>
user = 'https://bugs.python.org/ocean-city'

bugs.python.org fields:

activity = <Date 2007-01-08.06:58:11.000>
actor = 'ocean-city'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2007-01-07.05:51:17.000>
creator = 'ocean-city'
dependencies = []
files = ['7700', '7701']
hgrepos = []
issue_num = 1629718
keywords = ['patch']
message_count = 5.0
messages = ['51686', '51687', '51688', '51689', '51690']
nosy_count = 3.0
nosy_names = ['loewis', 'rhettinger', 'ocean-city']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1629718'
versions = ['Python 2.5']

[ocean-city]

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.

[loewis]

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.

[rhettinger]

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).

[ocean-city]

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

[ocean-city]

see the endless discussions on python-dev...

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