[Python-Dev] file.readinto performance regression in Python 3.2 vs. 2.7? (original) (raw)

Matt Joiner anacrolix at gmail.com
Thu Nov 24 23:02:15 CET 2011

What if you broke up the read and built the final string object up. I always assumed this is where the real gain was with read_into. On Nov 25, 2011 5:55 AM, "Eli Bendersky" <eliben at gmail.com> wrote:

On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Thu, 24 Nov 2011 20:15:25 +0200 Eli Bendersky <eliben at gmail.com> wrote: > > Oops, readinto takes the same time as copying. This is a real shame, > because readinto in conjunction with the buffer interface was supposed to > avoid the redundant copy. > > Is there a real performance regression here, is this a well-known issue, or > am I just missing something obvious?

Can you try with latest 3.3 (from the default branch)? Sure. Updated the default branch just now and built: $1 -m timeit -s'import filereadbytearray' 'filereadbytearray.justread()' 1000 loops, best of 3: 1.14 msec per loop $1 -m timeit -s'import filereadbytearray' 'filereadbytearray.readandcopy()' 100 loops, best of 3: 2.78 msec per loop $1 -m timeit -s'import filereadbytearray' 'filereadbytearray.readinto()' 1000 loops, best of 3: 1.6 msec per loop Strange. Although here, like in python 2, the performance of readinto is close to justread and much faster than readandcopy, but justread itself is much slower than in 2.7 and 3.2! Eli

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20111125/86a8864a/attachment-0001.html>

More information about the Python-Dev mailing list