Re: CLR Memory Footprint

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Ian Griffiths [C# MVP] (ian-interact-sw_at_nospam.nospam)
Date: 12/01/04

  • Next message: Alessandro Catorcini [MSFT]: "RE: Loading svr build of CLR for my .net Windows Service" 
    Date: Wed, 1 Dec 2004 09:31:59 -0000

    The memory footprint can be a big issue with the CLR. You're looking at a
    minimum of 4.5MB per process in my experience, and that's for very simple
    use of the CLR. It tends to be a lot more if you use any of the substantial
    areas of the framework class libraries.

    If your code is going to run in lots of processes, you can mitigate some of
    the hit with NGEN. This tool, which is part of .NET, precompiles your
    component rather than relying on JIT compilation. (NGEN is short for Native
    code GENeration.) This enables the compiled binaries to be shared between
    processes in the usual way that Windows binaries work. (This sharing
    doesn't occur today if you use the normal JIT compilation.)

    However, that just mitigates the code-related working set hit. I'm not
    really sure what proportion of the typical memory costs of using the .NET
    framework are down to code and how much is down to other use of memory.
    (And the only way to be sure would be to try out a few scenarios and measure
    them) 

    -- 
Ian Griffiths - http://www.interact-sw.co.uk/iangblog/
DevelopMentor - http://www.develop.com/
"Eric Smith" wrote:
> I'm working on a project that integrates with Office and the Windows 
> shell. Right now we have add-ins for Excel, PowerPoint, Word and Outlook, 
> and a couple of shell extensions for Windows Explorer, all written in C++.
>
> We're at a point where we want to overhaul some of this stuff, so we're 
> considering whether to use C# instead of C++. There are lots of huge 
> advantages to C#, but we're concerned about the memory footprint of the 
> CLR.
>
> As I understand it, we'd have a separate CLR for each process, meaning 
> someone using multiple Office applications simultaneously could be hit 
> pretty hard memory-wise with all those managed add-ins.
>
> Is this an accurate view? Is there anything we can do to alleviate the 
> problem?
>
>
  • Next message: Alessandro Catorcini [MSFT]: "RE: Loading svr build of CLR for my .net Windows Service"

    Relevant Pages

    • Re: virtual memory leak? in asp.net app - OutOfMemory exception
      ... I'm shocked that the CLR would not release memory back to Windows. ... HeapCreate specifies both an initial size and a maximum size for the heap. ... I don't know if the CLR uses HeapCreate or not, ...
      (microsoft.public.dotnet.framework.clr)
    • Re: GC.Collect can be trusted?
      ... compact the heap. ... It's not the task of the GC to return the memory to the OS, ... contain any GC heap data (managed objects and other CLR data). ... the memory manager won't ever return the default process heap segments occupied by ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Assembly memory limit exception -WHY?
      ... Asking for 700-800 MB of continuous memory is a ... CLR DLL's and Windows system DLL's and private user ... The managed heap allocated by the CLR ... >From this 1.2GB the CLR will allocate it's Large Object heap, ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Getting out of memory exception using SealMessage()
      ... The CLR allocates memory from the GC heap, ... handles our TLS encryption between client and server. ... The connections will start dropping. ...
      (microsoft.public.windowsce.platbuilder)
    • Re: Understanding the Dispose method and datasets?
      ... The CLR has plenty of rich metadata to draw from. ... Every application then has a set of 'roots', ... or static variables that are referencing objects in memory. ... workstation garbage collectors. ...
      (microsoft.public.dotnet.framework.aspnet)