Question

What are some tips to reduce the memory usage of .NET applications? Consider the following simple C# program.

class Program
{
    static void Main(string[] args)
    {
        Console.ReadLine();
    }
}

Compiled in release mode for x64 and running outside Visual Studio, the task manager reports the following:

Working Set:          9364k
Private Working Set:  2500k
Commit Size:         17480k

It’s a little better if it’s compiled just for x86:

Working Set:          5888k
Private Working Set:  1280k
Commit Size:          7012k

I then tried the following program, which does the same but tries to trim process size after runtime initialization:

class Program
{
    static void Main(string[] args)
    {
        minimizeMemory();
        Console.ReadLine();
    }

    private static void minimizeMemory()
    {
        GC.Collect(GC.MaxGeneration);
        GC.WaitForPendingFinalizers();
        SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle,
            (UIntPtr) 0xFFFFFFFF, (UIntPtr)0xFFFFFFFF);
    }

    [DllImport("kernel32.dll")]
    [return: MarshalAs(UnmanagedType.Bool)]
    private static extern bool SetProcessWorkingSetSize(IntPtr process,
        UIntPtr minimumWorkingSetSize, UIntPtr maximumWorkingSetSize);
}

The results on x86 Release outside Visual Studio:

Working Set:          2300k
Private Working Set:   964k
Commit Size:          8408k

Which is a little better, but it still seems excessive for such a simple program. Are there any tricks to make a C# process a bit leaner? I’m writing a program that’s designed to run in the background most of the time. I’m already doing any user interface stuff in a separate Application Domain which means the user interface stuff can be safely unloaded, but taking up 10 MB when it’s just sitting in the background seems excessive.

P.S. As to why I would care — (Power)users tend to worry about these things. Even if it has nearly no effect on performance, semi-tech-savvy users (my target audience) tend to go into hissy fits about background application memory usage. Even I freak when I see Adobe Updater taking 11 MB of memory and feel soothed by the calming touch of Foobar2000, which can take under 6 MB even when playing. I know in modern operating systems, this stuff really doesn’t matter that much technically, but that doesn’t mean it doesn’t have an affect on perception.

Answer 1

1. You might want to check out Stack Overflow question .NET EXE memory footprint.
2. The MSDN blog post Working set != actual memory footprint is all about demystifying the working set, process memory and how to perform accurate calculations on your total in-RAM consumption.

I will not say that you should ignore the memory footprint of your application — obviously, smaller and more efficient does tend to be desirable. However, you should consider what your actual needs are.

If you are writing a standard Windows Forms and WPF client applications which is destined to run on an individual’s PC, and is likely to be the primary application in which the user operates, you can get away with being more lackadaisical about memory allocation. (So long as it all gets deallocated.)

However, to address some folks here who say not to worry about it: If you’re writing a Windows Forms application which will be running in a terminal services environment, on a shared server possibly utilized by 10, 20 or more users, then yes, you absolutely must consider memory usage. And you will need to be vigilant. The best way to address this is with good data structure design and by following best practices regarding when and what you allocate.