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" <eli...@gmail.com> wrote:
> On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou <solip...@pitrou.net> wrote: > >> On Thu, 24 Nov 2011 20:15:25 +0200 >> Eli Bendersky <eli...@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 fileread_bytearray' 'fileread_bytearray.justread()' > 1000 loops, best of 3: 1.14 msec per loop > $1 -m timeit -s'import fileread_bytearray' > 'fileread_bytearray.readandcopy()' > 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! > > Eli > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
