Re: hackerlab fsplay.[ch] status

Tom Lord <lord-1tv/[email protected]> writes:

>     > From: Andreas Rottmann <[email protected]>
>
>     > I've started porting the GLib memchunk implementationn to
>     > hackerlab. 
>
> Why?
>
[snip]

Now that I did speed tests on alloc and free memchunks, I was not all
that convinced they make sense anymore (they are noticably slower than
malloc()/free()). However, I have now optimized the memchunk as not to
use binary trees but bit masking and posix_memalign(3) (suggested by
Owen Taylor on #gtk+) to find the area for a block, and now the speed
is about the same as for malloc()/free().

> What's the case for having this facility?
>
Well, glibc (so I've heard) imposes a 4-byte overhead on each
allocated piece of memory (it has to know the size). I thought we'd
want to save that for object data areas, since hashq values might be
used *very* often (additionally, with lim_malloc(), when using limits,
the overhead increases by another 4 bytes).

Andy
-- 
Andreas Rottmann         | [email protected]      | [email protected] | [email protected]
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!