Board index » cppbuilder » Tray application increases memory usage

Tray application increases memory usage

2004-03-01 06:23:41 PM
Hello newsgroup.
Maybe my problem was already discussed before but I did not find a hint.
I wrote a little web server application using Indy components and the
tray component TTrayIcon to hide the GUI. The application is doing fine.
Having a look at the memory usage in the Task Manager I've recognized
that the application is increasing memory usage the longer it is
running. So, I checked if all threads and classes are freed correctly -
and they did.
And now it is getting really wired. After maximizing the tray
application and minimizing it the Task Manager shows that the memory
usage is decreasing massivly (e.g. from 20 MB to 1 MB). After this the
memory usage is increasing slowly again.
I'm using CBuilder 6, SP1.
My questions are:
Is this behavoir by design?
If yes, why is it behaving this way?
If no, are there any known bugs, problems, workarounds?
Any help is welcome.

Re:Tray application increases memory usage

On Mon, 01 Mar 2004 11:23:41 +0100, Peter Schmitt wrote:
Is this behavoir by design?
If yes, why is it behaving this way?
If no, are there any known bugs, problems, workarounds?
This has been seen before by many people (including us). It appears to
result from excessive fragmentation of the heap. As you may know memory is
not allocated directly from the operating system but is instead allocated
through the Heap Manager (HM).
What a typical HM does is allocate large chunks at a time from the OS and
then suballocate these to your application.
IOW:When you first ask for 16 bytes the HM might ask the OS for 4kB (the
figures used here are likely innaccurate, I give them only for example) and
then returns to you a pointer to byte 0. When you ask for another 16 bytes
the HM just returns a pointer to byte 16 of the same block.
If you then delete the first pointer the HM can't return it to the OS so it
just records those bytes in its free list. If you ask for another 16 bytes
then the HM returns the first address again.
Where things get complicated is when you ask for 8 bytes after deleting the
first pointer. The HM /could/ return either the first address again or it
could return a third address pointing to byte 24. There are obvious
performance issues that determine which it does.
As you can probably see a program performing a lot of different size
allocations can end up leaving lots of small blocks of heap lying around on
the free list.
For some reason the Borland HM seems to have a weakness in this area. It
may be that it limits the size of the free list for performance reasons (it
must take time to search this list and after a while it may be better to
waste memory than delay allocations for too long) or it may be a bug. We
first saw this with BC4.5 and have subsequently noted it in BC5 and BCB.
The solution we adopted was to implement our own caching allocation class.
This is a crude class that can be used for a particular subset of
If you are sufficiently knowledgeable in C++ you can provide your own HM
but we found that simply giving known "trouble maker" modules access to
this class was enough to solve the problem.
Andrue Cope
[Bicester UK]

Re:Tray application increases memory usage

Hello Andrue,
thank you for your detailed answer. You give me a real good overview of
what is happening.
So I'll have to use an own HeapManager for my application to avoid the
heap fragmentation. That really hurts me. I'm not really a C++ guru and
furhtermore I'm using many components provided by Borland (for instance
TThread). I'm not quite sure if it possible to enforce "foreign"
components to use another HM then the default one.
But anyway thanks a lot for your help.