.Net exe memory footprint

Question

Even a simple notepad application in c# consumes megabytes of ram as seen in the task manager. On minimizing the application the memory size in the task manger goes down considerably and is back up when the application is maximized.

I read somewhere that the dot net process reserves a lot of memory for runtime allocation in advance thats why dot net apps have larger memory footprint to start with. But this memory can be released using win32 api call a trade off is that runtime allocation becomes slow - is that true ?

Answer 1

The reason for the large memory footprint is that the JIT compiler and WinForms engine are being loaded with your process. To reduce this, you can do the following:

[DllImport("psapi.dll")]
static extern int EmptyWorkingSet(IntPtr hwProc);


static void MinimizeFootprint()
{
    EmptyWorkingSet(Process.GetCurrentProcess().Handle);
}

This should remove as much as possible from your memory footprint. There may be a way that you can also reduce the amount of memory that is set aside for runtime memory allocation.

Answer 2

The task manager does not show real life usage of memory for a .NET app. To see that you almost have to put a performance counter on the app or use a profiler.

What you see in the Task Manager is the working memory of an app which includes a bunch of overhead for the framework itself which must also load when your app loads.

Answer 3

TaskManager should not be used to measure the memory footprint of a .NET application.

When a .NET application starts, it asks the OS for a chunk of memory which it then segments to become the managed heap, stack, and large object heap. It is this total chunk of memory that TaskManager is reporting, which may or may not be completely used by .NET. Once a .NET application is given a chunk of memory, it will not release it until asked by the OS, which will only happen with the OS determines a need for more memory resources.

If you want to measure memory allocations, you need to look at the various performance monitor (PerfMon) counters.

You can use interop code to call Win32 APIs to trim your working set size, but the next time your application requests memory from the OS the working set will go back up and there will be a performance hit while the OS allocates and hands out the additional memory and the .NET runtime "configures" it.