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 neologix
Recipients dmalcolm, eli.bendersky, flox, kaifeng, neologix, pitrou, python-dev
Date 2011-11-25.21:51:17
SpamBayes Score 2.7648618e-06
Marked as misclassified No
Message-id <CAH_1eM1j9-zMNWP2Sxe4sZFYM16Ejezw9FxQk+Z3qtXD6mqmzA@mail.gmail.com>
In-reply-to <1322225576.44.0.73701624914.issue11849@psf.upfronthosting.co.za>
Content
> However, there's still another strange regression:
>
> $ ./python -m timeit \
>   -s "n=300000; f=open('10MB.bin', 'rb', buffering=0); b=bytearray(n)" \
>   "f.seek(0);f.readinto(b)"
>
> -> default branch:
> 10000 loops, best of 3: 43 usec per loop
> -> default branch with patch reverted:
> 10000 loops, best of 3: 27.5 usec per loop
>
> FileIO.readinto executes a single read() into the passed buffer.

On my box:
default:
$ ./python -m timeit -s "n=300000; f=open('/tmp/10MB.bin', 'rb');
b=bytearray(n)" "f.seek(0);f.readinto(b)"
1000 loops, best of 3: 640 usec per loop

default without patch ("$ hg revert -r 68258 Objects/obmalloc.c && make"):
$ ./python -m timeit -s "n=300000; f=open('/tmp/10MB.bin', 'rb');
b=bytearray(n)" "f.seek(0);f.readinto(b)"
1000 loops, best of 3: 663 usec per loop

I'm just observing a random variance (but my computer is maybe too
slow to notice).
However, I really don't see how the patch could play a role here.

Concerning the slight performance regression, if it's a problem, I see
two options:
- revert the patch
- replace calls to malloc()/free() by mmap()/munmap() to allocate/free
arenas (but I'm not sure anonymous mappings are supported by every OS
out there, so this might lead to some ugly #ifdef's...)
History
Date User Action Args
2011-11-25 21:51:18neologixsetrecipients: + neologix, pitrou, eli.bendersky, flox, dmalcolm, python-dev, kaifeng
2011-11-25 21:51:17neologixlinkissue11849 messages
2011-11-25 21:51:17neologixcreate