> They're indistinguishable then on my box (on one run xreadlines is .1 > seconds (out of around 7.6 total) quicker, on another readlines_sizehint), > *provided* that I specify the same buffer size (8192) that xreadlines uses > internally. However, if I even double that, readlines_sizehint is uniformly > about 10% slower. It's also a tiny bit slower if I cut the sizehint buffer > size to 4096. > > I'm afraid Mysteries will remain no matter how many person-decades we spend > staring at this <0.5 wink> ... 8192 happens to be the size of the stack-allocated buffer readlines() uses, and also the stdio BUFSIZ parameter, on many systems. Look for SMALLCHUNK in fileobject.c. Would it make sense to tie the two constants together more to tune this optimally even when BUFSIZ is different? --Guido van Rossum (home page: http://www.python.org/~guido/)
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