🚀 go-pugleaf

It is because Windows allocates more memory than is really needed, and calls
it the app's virtual memory pool. Whenever the app requires more memory,
Windows tries to allocate it from the app's VM pool, and if there is
insufficient, Windows gives a large chunk over to the app's VM pool, and then
app takes memory from that. If you are seeing what memory is free under
Windows Task Manager or suchlike, it won't properly reflect what the app has
asked for and what it has freed.
-- 
Mark Jacobs
DK Computing
http://www.dkcomputing.co.uk

"Matija" <matija@REMOVEtel.fer.hr> wrote in message
news:419c6b3c$1@newsgroups.borland.com...
| It is about the same application I reported being much faster on AMD than
| Intel P4...
|
| There are extensive calculations being made, but all algorithms use objects
| instead of some simple data types. Of course, that decreases performances
| due new/delete memory reservation and restoration...
|
| But, after calculation were completed I checked TaskManager memory usage -
| in test case almost 65 MB of memory is used even though I deleted all
| object.
| First, I thought it is just a new case of memory leak, so I added
| ObjectCollector class that included some static list for collecting pointers
| to objects of certain type. Also, to each class I added static int counter
| to find out which object are not deleted (standard inc/dec of these counters
| was included in constructors/destructors).
|
| There were some objects left (yes, many of them - some 40000 objects of one
| type). And all pointers were properly listed in ObjectCollector list. So,
| after finishing calculations, I just wanted to clear them.
|
| I 'scrolled' through list, deleted all objects and hoped to free memory. But
| no!
| Destructors were called (I traced whole code), counters decreased etc. All
| object were delete for sure, but no memory was freed!
|
| Then, I tried to do additional 100000 objects of that same type just before
| deleting ObjectCollector list. All new objects were added to ObjectCollector
| list (I add reference to object in its class constructor, just before
| increasing class object counter).
|
| So, the same loop for deleting object now had 140000 steps to do.
| And it freed memory allocated for these new 100000 objects, but didn't for
| rest of 40000 objects!
|
|
| Any ideas? Is it because of 'randomly' created objects during calculations,
| so that WinXP memory management can not free compact part of memory or what?
| Are there any additonal functions to free memory directly (I looked for
| GetHeapStatus and other ShareMem.h functions, but it constantly returns NULL
| to me, event though I don't use any special memory management)?
|
|
|