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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4