> * The debug DLLs of coreclr.dll and clrjit.dll are 4x bigger than the release DLLs.
> * The debug versions allocate more at runtime.
Yeah, that's a good point. I'm going to update the post with RELEASE mode values, so that it's a better representation of a real app.
> On my computer I'm seeing something like 98MB commited, 8MB private, and 14MB working set. The committed number is not useful, as it a lot of DLLs get loaded in that only have a few functions in them called. The most charitable metric would be private work setting, which is 4MB.
The more I dug into this, the more I came to the conclusion that there is no one number that reflects the memory usage of an application, as you say, you almost always need to look at several values.
It's a good job VMMap exists as it makes it really easy to see the different values, I especially like that it detects the GC Heap as a separate category.
Yeah, that's a good point. I'm going to update the post with RELEASE mode values, so that it's a better representation of a real app.
> On my computer I'm seeing something like 98MB commited, 8MB private, and 14MB working set. The committed number is not useful, as it a lot of DLLs get loaded in that only have a few functions in them called. The most charitable metric would be private work setting, which is 4MB.
The more I dug into this, the more I came to the conclusion that there is no one number that reflects the memory usage of an application, as you say, you almost always need to look at several values.
It's a good job VMMap exists as it makes it really easy to see the different values, I especially like that it detects the GC Heap as a separate category.