| From: | Allan Odgaard |
| Date: | 14 Aug 2000 at 09:25:45 |
| Subject: | Re: memory allocation fcns |
On 13-Aug-00, Alexander Niven-Jenkins wrote:
>> Exactly what do you want? [...]
> Every thing and anything :-)
Well, if I find the time I can write a tutorial about the subject, but
it's probably only of real use to poeple who develop their own OS or
similar "large" system like a database etc...
But a general tip is for example if you need to load and parse a big
file which results in many small allocations, which are all live, then
allocate e.g. 8 kb chunks and use them up linearly, without tagging the
allocations. This will give only a few cycles overhead but even
better, when you're done with the file you can free all the allocations
in one go, and are not stuck with any fragmentation.
> I have got a newer version of the routine which only reallocates
> the memory on change of length (I havn't implemented this yet)
> Read length
> if( length != prevlength )
You could do: if(length > prevlength)
> {
> delete[] data;
> data = new char[ length ];
Here you could do:
delete[] data;
prevlength = (length + 31) & ~31;
data = new char[prevlength];
Because I'm quite sure this rounding is performed by AllocMem, so why
not do it yourself, so that if one length is 11 bytes and the next is
15, there's no need to re-alloc memory.
> }
> Read lengh bytes into data;
> // do stuff with data
> This must fragment memory etc, and I was wondering if there was a
> better way...
I don't think there's any fragmentation. When you free the data then
it's added to the free list, and if possible, collapsed with any
consecutive free chunks. Since it was AFAI-can-tell the last chunk to
be allocated, then it can be collapsted with any chunk that it may have
been part of, before being splitted for allocation, so you do have a
little code overhead, but you shouldn't be fragmenting the freelist.
Btw: you may want to run some profiling tool to see if it actually makes
sense to spend time optimizing this little bit of code ;-)
Regards Allan