[Python-Dev] file.readinto performance regression in Python 3.2 vs. 2.7?
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
>> > 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 fileread_bytearray' 'fileread_bytearray.justread()'
> 1000 loops, best of 3: 1.14 msec per loop
> $1 -m timeit -s'import fileread_bytearray'
> 100 loops, best of 3: 2.78 msec per loop
> $1 -m timeit -s'import fileread_bytearray' 'fileread_bytearray.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!
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev