Home/ Questions/Q 8425723
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T04:21:05+00:00

I’m trying to tackle down some memory usage issues. Overall my application collects a

  • 0

I’m trying to tackle down some memory usage issues. Overall my application collects a few data values and visualizes them using a C1 WPF charts and datagrids finally putting everything into PDF reports.

Profiling my process using YourKit I’m faced with the situation, that the CLR heap size is ~120MB (which is all fine) while the process memory size is ~580MB. This is nearly 5 times the memory consumption of my actual CLR heap size. My CLR peak size was 220MB vs. 710MB process memory allocation.

I’m well aware that there is some overhead required on my object heap, stacks and so on. In Java JVMs the typical factor I’m used to was around ~1.5x.

How can this excessive memory overhead be explained? Is the processs just allocating free spare heap space? If yes, does this explain the 710MB vs. 220MB?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A couple of additional notes here. Though I’m not exactly sure what you mean by "CLR Heap Size".
    Depending on the .NET Runtime you’re using, there are 8 or 9 different heaps that the CLR uses – so the memory you see in the Heap Size vs. VM size accounts for some of the difference:

    1. Loader Heap: contains CLR structures and the type system
    2. High Frequency Heap: statics, MethodTables, FieldDescs, interface map
    3. Low Frequency Heap: EEClass, ClassLoader and lookup tables
    4. Stub Heap: stubs for CAS, COM wrappers, P/Invoke
    5. Large Object Heap: memory allocations that require more than 85k bytes
    6. GC Heap: user allocated heap memory private to the app
    7. JIT Code Heap: memory allocated by mscoreee (Execution Engine) and the JIT compiler for managed code
    8. Process/Base Heap: interop/unmanaged allocations, native memory, etc
    9. added in .NET 5: Pinned Object Heap (POH)

    Two other items which can cause excessive memory usage are memory fragmentation (mostly occurs on the LOH or large object heap) or a high number of Threads.

    There are many causes for memory fragmentation and the best way to rule this out is to use WinDbg to analyze the segment sizes for each segment on the GC Heap.

    As far as a high number of threads, you have either 1MB (for x86 process) or 4MB (for x64 process) of stack space allocated for each thread that your app uses. This memory is placed in the Process/Base Heap. Therefore if you have 100 threads, you can have up to additional 100MB/400MB of memory usage.

    HTH

    • 0