Sv: Memory allocators

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

>Sounds cool. The benchmark results are also very nice (I just don't
>understand the small difference between blocksizes of 16 and 128). And most
>important this stuff cuts down on memory fragmentation. good.
>
You shouldn't put too much faith into those benchmarks. I only did 3 test
runs for each.

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.

>The bad news is that I don't have too much time right now and so it's
>likely to take some time until they really make it into the code. Perhaps
>it's better to add them *after* the rewrite of the URL processing code and
>the dir management stuff, perhaps it's better to add them *while* rewriting
>these things. I'll start coding tonight, so we'll see.
>
I don't think it really matters. But I think its best if you do it
afterwards, because I won't get things ready for today (there's an elusive
bug somewhere).

>In any case, adding the stuff should mainly be a metter of replacing "new"
>calls with calls to the custom allocator, right?
>
Exactly.

>(BTW - how do you handle out-of-memory situations?)
>
Well, doesn't new throw an exception if it fails? I'm not catching any
exceptions from new, so I handle out-of-memory exactly like new does.