Large initial memory footprint for native app

Question

Hi,

I've noticed that the native C++ application I'm working on has quite a large memory footprint (20MB) even before it enters any of my code.

(I'm referring to the "private bytes" measure in Windows, which as I understand it is the most useful metric).

I've placed a break point on the first line of the "main()" function and sure enough, the footprint is at 20MB when it reaches that.

The size of the EXE is only a couple of meg so that doesn't account for it.

I also deliberately removed all of the DLLs just to prove they weren't the cause. As expected it gets a "Dll not found" message, but the footprint is still 20MB!

So then I wondered that maybe it was the statically initialised objects which were the cause.

So, I added breakpoints to both "new" and "malloc". At the first hit to those (for the first static initialiser), the memory is already 20MB.

Anyone got any ideas about how I can diagnose what's eating up this memory?

Because it seems to be memory outside of the usual new/malloc paradigm, I'm struggling to understand how to debug.

Cheers,

John

Answer 1

You might compile your app without debug information and see if this changes something, debugging ability eats quiet some memory.

Answer 2

On my system, a simple MFC app and an empty Delphi app both take about the same number of private bytes - around 400K. So if your app is grabbing 20Mb, it is definitely sometyhing that your application is doing, and not some OS bloat. You need to post more details of what your app does, what libraries it uses etc.

Answer 3

It might be that you're pulling a lot of libraries with your app. Most of them get initialized before execution is handed over to your main(). Check for any non-standard libraries you're linking against.

EDIT: A very straightforward solution would be to create a new project and just link the libraries you're using one by one, checking memory usage each time. Even though it's an ugly approach, you should find the culprit this way.

There's probably a more elegant solution out there, so you might want to spare some time googling for (free) memory profiling solutions.