Christian Heimes wrote:
> Andrew MacIntyre wrote:
>> I tested the updated patch you added to issue 2039. With the int
>> freelist set to 500 and the float freelist set to 100, its about the same
>> as the no-freelist version for my tests, but PyBench shows the simple
>> float arithmetic to be about 10% better.
>>
>> I'm inclined to set the int LIFO a bit larger than you suggest, simply as
>> ints are so commonly used - hence the value of 500 I used. Floats are
>> much less common by comparison. Even an int LIFO of 500 is only going to
>> tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant
>> enough that I can't see a need for a compaction routine.
>>
>> A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on
>> 64bit).
>
> I added some profiling code to lists and dicts. Increasing the free list
> size didn't make a difference for lists and dicts. I used 200 instead of
> 80 for the free list size and the ratio of reuse / allocation increased
> minimal.
>
> Every entry in the free list costs 4 bytes for the pointer and 16 bytes
> for the int or float object on 32bit including padding on 8byte address
> boundaries. For 500 objects that's about 9kb which isn't a big deal
> nowadays. But - andere there is always a but - every object may keep a
> 4kb arena alive.
The 4kB entities are "pools" (for allocation size classes); arenas are
the 256kB chunks of memory PyMalloc gets from the platform malloc. One
active allocation in any size class from a pool in an arena will prevent
release of an arena.
> Unless a program is creating and destroying lots of ints at once a
> larger number doesn't make a performance difference. I'd stick to 80,
> maybe 120 for ints for now.
My thinking was that the price (& I was forgetting that the 12 byte int
object still gets a 16 byte allocation) was small enough that being
generous minimises surprises in production code; after all, we've been
doing this research with synthetic microbenchmarks.
When you get right down to it, the object freelist offers such a small
gain that its real value is in the noise in many cases despite being
measurable.
After all, PyMalloc is nothing but a highly optimised package of
freelists with the malloc()/realloc()/free() API... It just does a bit
more book-keeping than the simple freelists used for ints and floats
(which predate PyMalloc being added to the source tree, let alone being
enabled by default).
I'm not that interested in debating the detail of exactly how big the
prospective LIFO freelists are - I just want to see the situation
resolved with maximum utilisation of memory for minimum performance
penalty. To that end, +1 from me for accepting your revised patch
against issue 2039. In addition, unless there are other reasons to
retain it, I would be suggesting that the freelist compaction
infrastructure you introduced in r60567 be removed for lack of practical
utility (assuming acceptance of your patch).
Cheers,
Andrew.
--
-------------------------------------------------------------------------
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
_______________________________________________
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
