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.08:17:06
SpamBayes Score 5.803979e-07
Marked as misclassified No
Message-id <CAH_1eM2pTRsFd86bmf-ztdVhfUHA3Cx7EPT2mjq1pxxbvWB4pQ@mail.gmail.com>
In-reply-to <1322181000.89.0.989499659253.issue11849@psf.upfronthosting.co.za>
Content
> For the record, this seems to make large allocations slower:
>
> -> with patch:
> $ ./python -m timeit "b'x'*200000"
> 10000 loops, best of 3: 27.2 usec per loop
>
> -> without patch:
> $ ./python -m timeit "b'x'*200000"
> 100000 loops, best of 3: 7.4 usec per loop
>

Yes, IIRC, I warned it could be a possible side effect: since we're
now using mmap() instead of brk() for large allocations (between 256B
and 32/64MB), it can be slower (that's the reason adaptive mmap
threadshold was introduced in the first place).

> More surprising is that, even ignoring the allocation cost, other operations on the memory area seem more expensive:

Hum, this it strange.
I see you're comparing 3.2 and default: could you run the same
benchmark on default with and without the patch ?
History
Date User Action Args
2011-11-25 08:17:07neologixsetrecipients: + neologix, pitrou, eli.bendersky, flox, dmalcolm, python-dev, kaifeng
2011-11-25 08:17:07neologixlinkissue11849 messages
2011-11-25 08:17:06neologixcreate