Re: Virtual Bytes is STL
anand chugh wrote:
On Aug 28, 3:44 pm, "Tom Widmer [VC++ MVP]" <tom_use...@hotmail.com>
wrote:
anand chugh wrote:
(1) Before call to funcStr(), Private Bytes=17MB, Virtual Bytes=18 MB
(2) After call to funcStr(),Private Bytes=85MB, Virtual Bytes=260 MB
(data collected from perfmon)
I couldn't replicate that - private bytes barely changed between 1 and
2, though virtual bytes did jump up (I'm guessing that HeapFree keeps
the pages reserved).
Is there any way to release the memory to OS rather than STL?I guess
implementing allocator would be soultion.
What compiler and standard library (STL) are you using? That would seem
to be essential information...
Tom
Private Bytes Changed from 17 MB to 85 MB and Virtual Bytes from 18
to 260MB
That can't be the program you posted - 17MB before its done anything!?
I am using Visual Studio 2005 and microsoft STL.
I couldn't replicate that behaviour on that platform with the code you
posted. Is your real program different (obviously, I added in the
necessary #includes, but otherwise left it alone, and tested both
release and debug builds).
On the release build I got:
Private bytes: 327860 -> 507905 (+170KB or so)
Virtual bytes: 7MB -> 40MB
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).
What OS are you using? At the lowest level, the allocator is actually
implemented by the OS, not the compiler (via the HeapAlloc, etc. APIs).
For example, Windows XP has a low fragmentation heap available (see
HeapSetInformation), and Vista I believe has a completely re-implemented
heap offering much better performance for multiCPU - it possibly
auto-switches to the LFH if it determines that it would be beneficial
for an application.
Actually this is
expected behaviour of STL , they have updated FAQ http://www.sgi.com/tech/stl/FAQ.html
Dinkumware's standard library (which is what MS use) does *not* use a
caching std::allocator, unlike SGIs (and STLport's) - calls are directed
straight through to operator new and operator delete. The SGI STL is not
the same as the C++ standard library, so any FAQs for SGI's STL may or
may not apply to any other standard library implementation, such as MS's.
Why does Bounds CheckerTM say that I have memory leaks?
[snip]
That does not apply to Dinkumware's STL - BoundsChecker won't report
those leaks with the VC2005 library AFAIK (it may report other leaks
associated with standard IOStreams objects, but that's a separate issue).
This is a serious using default allocators, causing a program to keep
that memory even if its not using that.
You can configure SGI's STL not to cache memory using a simple #define.
But that's pretty irrelevant since you're using VC2005...
Tom