[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Functions and memory usage
- From: "Nick Trout" <ntrout@...>
- Date: Thu, 17 Oct 2002 16:05:53 -0700
> 200k/300k of internal structures of the allocator on 100Mb of
> allocated memory sound
> pretty good to me, I do not understand the smile :-)
Then its not memory wasted, its used to manage the memory management. I
assumed you meant that 200k-300k is lost to spaces at the end of pages,
and rounding up, as you describe.
The smile was to show that while I might be aiming a criticism at you
there is no malice intended! Its all a bit dry this technical mumbo
jumbo sometimes and email can often be read ambiguously.
> > I assume each pool size would have an most recently used stack, only
> > allocating a new pool once you've checked the existing
> pools for space?
> I don't really understand the question :P
> What do you mean as most recently used stack?
What happens when you deallocate/free an object? Lets say you allocated
10 pools (4k blocks) of 16 byte objects and then free a load of them. If
you then wanted to allocate a new 16 byte object, how would that be
done? I assume for fast allocation you would keep track of pools, and
group them by size of object, so you could quickly find a pool
containing 16 byte objects to allocate from. I was speculating that a
set of stacks of pools might be a good way to organise this. When a new
pool of a certain size is required it is pushed onto the stack and can
be accessed quickly. However when deallocation takes place this might
not be the best idea. I'd be interested to know how this is managed
since you mention your free time was greatly reduced.
If you are allocating 100Mb then this would be beyond the scope of
certain platforms and so a system like yours may not be as efficient or
suitable for all applications. The dlmalloc system may be a better