Re: Virtual Bytes is STL
anand chugh wrote:
On Aug 28, 4:52 pm, "Tom Widmer [VC++ MVP]" <tom_use...@hotmail.com>
wrote:
Virtual bytes are of very minor concern, since virtual memory is a
per-process resource (a process can reserve its full 2GB (or 3GB) of
virtual memory with no performance impact on other processes). That
virtual memory address space should be recommitted by the allocator as
necessary for future allocations (using any of STL, new and malloc).
I was mainly concerned with Virtual Bytes. Private Bytes ie actually
coming down .
As per results Virtual Bytes 7->40 , so 33 MB for vector of 100000
with small strings. There may be cases when we have vector of objects
with size more than 500000 . I am facing such scenerios in my
program .In that case that would be noticable difference. Will this
cannot called be Virtual Bytes Leak?
You can't really leak virtual bytes, since they don't exist except in
the address space of a single process, and they aren't exactly leaked
since they are still available for that process to use for any call that
uses the process heap (e.g. new/malloc/HeapAlloc(GetProcessHeap(),
....)). The one genuine problem that you may find is that, over time,
your ability to make single extremely large allocations (e.g. a
contiguous chunk of 500MB) in your process becomes curtailed, but if
your program may need to do that, you can reserve some space up front
using VirtualAlloc.
Memory in a single process can be in lots of states:
Unreserved - memory from the 2-3GB is available for new virtual
allocations in the process.
Reserved - Address ranges that don't have any information in them, but
which can't be used by other virtual allocations in the same process.
Committed - Address ranges that are backed up by real bytes, either in
the page file or in physical memory.
A caching STL such as SGI's caches committed memory. All non-specialist
Windows applications (e.g. those that ultimately make use of the Heap*
functions for memory allocations), including those written in VC2005
with STL code, cache reserved memory. Perhaps one day MS will add a
HeapCompact function, that unreserves all unused virtual memory, but it
isn't available yet, and it is very rarely needed...
Tom