[Python-Dev] Patch #552433

[Martin v. Loewis]

Guido van Rossum <guido@python.org> writes:

> I've missed the review of this patch.  Why bother special-casing
> tuples?  Who's ever going to iterate over a tuple long enough that it
> makes a difference?

Notice that the length of the tuple is not an issue - or rather, the
longer the tuple, the less interesting this change.

When profiling, I found that Python, with iterators, spends a
significant amount of time in allocating IndexError exceptions, so I
thought that patch makes sense. There is also speed to be gained from
accessing the tuple directly (thus bypassing the function call), but
that may not be so relevant.

I have now tried to measure code usage of this change, using two
metrics:

listcount,tuplecount,othercount: 
  Number of times the list, tuple, and "other" case is taken
listlast,tuplelast,otherlast:
  Number of times that the return NULL is taken for each case

I made the following runs:

print "Hello":     1744        149         70
                     69         60         13

make sharedmods:   14217      2142        447
                     641       949         60

regrtest.py:     3184596    152384    1170921
                  134457     49271      15765

PyXML testsuite:  713585    110278       7192
                   21306      2357       2964

As you can see, the percentage of cases in which iternext is called
for a tuple varies between 3% (regrtest) and 13% (PyXML). However, the
percentage of exhausted tuples compared to other exhausted containers
varies between 8% (PyXML) and 61% (make sharedmods).

So it appears that a significant fraction of the exhausted containers are
indeed tuples, justifying the special-casing.

Regards,
Martin