Re: Memory management terminology
On average, sdt::string<> and std::vector<> are randomly sized,
but frequently allocated/deallocated/resized.
std::map<> and std::queue<> have nodes that are fixed size,
given their type instantiation.
Having same-sized allocations with diverse lifetimes is not as bad
as having short-lived & variable-sized allocations interspreaded
with long-lived & fixed size allocations.
Let me make a trivial example:
class BufferHolder {
ULONG m_RefCount
BYTE m_SomeArray[];
};
BufferHolder::DoSomething(int Number){
delete [] m_SomeArray;
m_SomeArray = new BYTE[rand() * Number];
}
BufferHolder is fixed size. In a reasonable implementation of a heap,
same-size blocks will be cached and reused. Since they are same-sized,
they will be natually clustered.
m_SomeArray is variable sized, and, it will be de-allocated and re-allocated
during the lifetime of the master object.
`m_SomeArray` is a natural candidate for a different
heap/allocator than `BufferHolder`.
Extending the concept, sometimes it can be noticed that ref-counted objects
live in constellations of essentially-same-lifetime objects with the
complication
of "storage" or "scratch/temporary" buffers.
The constellation can sometimes be implemented by a "master' object,
to avoid heap fragmentation.
Probably nothing of this is all new or applicable, but, log-running
heap-intensive applications might need to go through this kind of analysis.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:eiqGVkdkGHA.2280@TK2MSFTNGP02.phx.gbl...
Ivan Brugiolo [MSFT] wrote:
It's hard to give good guidelines without analizing first the typical
behavior
of the application over a long period of time.
General recomendations could be:
- enable LowFragHeap, if you have reasonably small, same-sized
allocations. - do not cluster long-lived and short lived allocations.
- ensure no address space fragmentation to allow for a healty growth
of the heap
- use multiple heaps if you have radically different lifetime
and size characteristics for your allocations
Thanks, it makes lots of sense. One thorny issue is the concept of
lifetime. In C++ code allocations are usually done by an object while its
lifetime may only be known to the creator or to nobody (in case of
reference couunted objects).
Not sure there is a good solution to this :-(
--
Eugene
http://www.gershnik.com