This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jcon
Recipients benjamin.peterson, daniel.urban, jcon, pitrou, stutzbach
Date 2011-05-07.21:43:43
SpamBayes Score 5.634826e-12
Marked as misclassified No
Message-id <1304804624.01.0.325988568291.issue9971@psf.upfronthosting.co.za>
In-reply-to
Content
It seems to me that the point of using readinto() is to avoid double-buffering (and the extra alloc/free that comes with read()). The slowness of using a small buffer size seems like only a natural and expected consequence. 

The trade-off of accommodating a small buffer size (by buffering behind the scenes anyways) would likely slow the more common cases which use a decent buffer size. I am wondering if an effort to accommodate both uses would be appropriate. Possibly by not double-buffering if readinto(b): len(b) > buffer_size/2 (arbitrary but seems feasible), and copying directly as the patch does now. Otherwise, fill the buffer up for subsequent reads and copy len(b) to user buffer. There is probably a good equilibrium for when it makes more/less sense to bypass the internal buffer.

Changing _bufferedreader_read_generic() would require some of the other helpers to be changed as well but it may be the way to go.

Let me know what you think of the above. I will experiment a bit. Unfortunately I am a bit busy this weekend but cannot wait to work on this again.
History
Date User Action Args
2011-05-07 21:43:44jconsetrecipients: + jcon, pitrou, benjamin.peterson, stutzbach, daniel.urban
2011-05-07 21:43:44jconsetmessageid: <1304804624.01.0.325988568291.issue9971@psf.upfronthosting.co.za>
2011-05-07 21:43:43jconlinkissue9971 messages
2011-05-07 21:43:43jconcreate