Sv: Sv: Memory allocators

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>>However, you are right, the difference is quite small, which indicates
that
>>more time is spent fooling around with the list of free units than the
list
>>of blocks. I can't say that surprises me very much. Larger block sizes
cuts
>>down on fragmentation, though.
>
>In some other mail I said something about specifying a size estimate to the
>allocator at construction time. What about doing something like
>blocksize = <est.size> * 1.1
>to minimize both reallocation and fragmentation?
>
A little bit of nitpicking, but the allocator never REallocates. It only
allocates and deallocates.

I think if people request a blocksize of, say, 24, then that's what they
should get. The client of the allocator probably knows best what blocksize
is the most appropiate blocksize. If the client of the allocator knows that
the blocksize passed in is only an estimate of the optimum, and it would be
beneficial to multiply the value with 1.1, then the client should do that,
not the allocator.

Basically, I think decisions should be made by code that has the best
information of the situation. IMHO This is not the code in the allocator.

We could make it an option dependant on a pre-processor symbol, though.
Something like PP_OPT_MEM_ALLOC_ENLARGE_BLOCKSIZE_REQUESTS. A bit long, but
then IMHO that's not so bad for these kinds of options, where clarity is
very important.