What "eats" memory in C++ ?

[Jarek]

Hi all!

I'm optimizing my C++ multi-threaded application (linux). My
application consumes huge amout of memory from unknown reason.
There are no memory leaks, or other allocation bugs, application
works well, but on startup it has about 200mb (VmSize).
How can I investigate what function/class/other takes so much memory ?
I tried to verify sizes of classes using sizeof, but it returns
so small values (<100 bytes), there are very little about of dynamic
memory allocations, and all of them are small, so I suspect that
most of this memory is consumed by C++ internally (libs ?).
How to check it, and how to improve it ?


regards
Jarek

 

[Gernot Frisch]

Hi all!

I'm optimizing my C++ multi-threaded application (linux). My
application consumes huge amout of memory from unknown reason.
There are no memory leaks, or other allocation bugs, application
works well, but on startup it has about 200mb (VmSize).
How can I investigate what function/class/other takes so much memory
?
I tried to verify sizes of classes using sizeof, but it returns
so small values (<100 bytes), there are very little about of dynamic
memory allocations, and all of them are small, so I suspect that
most of this memory is consumed by C++ internally (libs ?).
How to check it, and how to improve it ?

overwrite the new operator and malloc functions in a global header
file and trace all the allocations made.

 

[msalters]

Hi all!

I'm optimizing my C++ multi-threaded application (linux). My
application consumes huge amout of memory from unknown reason.
There are no memory leaks, or other allocation bugs, application
works well, but on startup it has about 200mb (VmSize).
How can I investigate what function/class/other takes so much memory ?
I tried to verify sizes of classes using sizeof, but it returns
so small values (<100 bytes), there are very little about of dynamic
memory allocations, and all of them are small, so I suspect that
most of this memory is consumed by C++ internally (libs ?).
How to check it, and how to improve it ?

The sizeof(vector<int>) doesn't report the memory used by the
integers, only the (constant) overhead to manage it. Same goes
for std::string, etc.

Regards,
Michiel Salters

 

[Tom Widmer]

Hi all!

I'm optimizing my C++ multi-threaded application (linux). My
application consumes huge amout of memory from unknown reason.
There are no memory leaks, or other allocation bugs, application
works well, but on startup it has about 200mb (VmSize).
How can I investigate what function/class/other takes so much memory ?
I tried to verify sizes of classes using sizeof, but it returns
so small values (<100 bytes), there are very little about of dynamic
memory allocations, and all of them are small, so I suspect that
most of this memory is consumed by C++ internally (libs ?).
How to check it, and how to improve it ?

http://en.wikipedia.org/wiki/Memory_debugger

Mpatrol sounds like it might do what you want (namely, tell you which
code is making the excessive memory allocations).

Tom

 

[Jarek]

Hi all!

I'm optimizing my C++ multi-threaded application (linux). My

I've found the solution: change memory monitoring software !

I've based my opinion about memory consumption, on gnome-system-monitor,
which badly counts memory for multithreaded programs. If some process,
has 5MB, but has 100 threads, gnome-system-monitor will show that this
process has 500MB!

regards
Jarek

 

[Tom Widmer]

I've found the solution: change memory monitoring software !

I've based my opinion about memory consumption, on gnome-system-monitor,
which badly counts memory for multithreaded programs. If some process,
has 5MB, but has 100 threads, gnome-system-monitor will show that this
process has 500MB!

That's a good point. When a thread is created it reserves address space
(e.g. virtual memory) for its stack, and this is often 4MB. Usually most
of that space won't be used, but it is reserved just in case the stack
grows to that size (since the stack must be contiguous). So although the
virtual memory usage appears high, the physical memory usage may be very
low (since only the first 4K page of each thread's stack is actually in
use).

Tom