[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: malloc (was Re: Another attempt at SpeedingUpStrings)
- From: Mark Hamburg <mhamburg@...>
- Date: Mon, 17 Dec 2007 09:29:48 -0800
on 12/17/07 7:56 AM, Rici Lake at firstname.lastname@example.org wrote:
> In principle, there is no
> reason why a malloc of 20033 bytes should be any slower than a malloc of
> 53 bytes, but the benchmark seems to indicate otherwise.
Small items probably come out of suballocators. Large items probably require
page allocations. So, while there is no reason why they have to have
different timings, I would actually expect a good malloc implementation to
have relatively different timings for these cases.
Speaking of which...
I've been thinking that it might be useful to build a suballocator for Lua's
memory allocator that would hold onto freed blocks until the next round
through the garbage collector. Has anyone played with anything like this.
The one crude part is that to get it going without changing the Lua VM, one
would basically need to have a userdata object with a __gc proc that would
essentially say "flush the free lists" but this isn't really quite the
message I'm looking for and probably means that memory retention on the free
lists is even higher than one might want.