Antoine Pitrou <pit...@free.fr> added the comment:
Oops... It hadn't jumped at me earlier, but the patch is actually problematic
performance-wise. The reason is that it doesn't buffer data at all, so small
readintos become slower (they have to go through raw I/O every time):
$ ./python -m timeit -s "f=open('LICENSE', 'rb'); b = bytearray(4)" \
"f.seek(0)" "while f.readinto(b): pass"
-> without patch: 2.53 msec per loop
-> with patch: 3.37 msec per loop
$ ./python -m timeit -s "f=open('LICENSE', 'rb'); b = bytearray(128)" \
"f.seek(0)" "while f.readinto(b): pass"
-> without patch: 90.3 usec per loop
-> with patch: 103 usec per loop
The patch does make large reads faster, as expected:
$ ./python -m timeit -s "f=open('LICENSE', 'rb'); b = bytearray(4096)" \
"f.seek(0)" "while f.readinto(b): pass"
-> without patch: 13.2 usec per loop
-> with patch: 6.71 usec per loop
(that's a good reminder for the future: when optimizing something, always try
to measure the "improvement" :-))
One solution would be to refactor _bufferedreader_read_generic() to take an
existing buffer, and use that.
----------
stage: needs patch -> patch review
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
