Memory Profile
ghassett
Posts: 3
This question has been asked before (http://www.red-gate.com/messageboard/viewtopic.php?t=633), and the topic was locked. I read the reply to that topic but am left wanting more information, so I'll repost the question in a new topic and hope that some ANTS users can post some pointers or explanations.
When running my application, Windows Task Manager reports a working set size of 30 MB. ANTS says my application is using 3 MB. In the reply to the earlier topic, it was suggested that perhaps the extra 27 MB is being taken up by "loaded dll’s and native code". Although I am sure that in the course of doing its business, my app loads and executes code from unmanaged DLL's, I cannot conceive of how that "unmanaged" work can use ten times as much memory as the core functionality of the application, which is in managed code.
My question is, how does one go about probing deeper into the descrepency (one order of magnatude!) between the working set size (as reported by Task Manager) and the sum of the actual allocations made by the managed code (as reported by ANTS profiler)?
Any and all help is very much appreciated....
Thanks
Greg
When running my application, Windows Task Manager reports a working set size of 30 MB. ANTS says my application is using 3 MB. In the reply to the earlier topic, it was suggested that perhaps the extra 27 MB is being taken up by "loaded dll’s and native code". Although I am sure that in the course of doing its business, my app loads and executes code from unmanaged DLL's, I cannot conceive of how that "unmanaged" work can use ten times as much memory as the core functionality of the application, which is in managed code.
My question is, how does one go about probing deeper into the descrepency (one order of magnatude!) between the working set size (as reported by Task Manager) and the sum of the actual allocations made by the managed code (as reported by ANTS profiler)?
Any and all help is very much appreciated....
Thanks
Greg
Comments
I can suggest using some performance counters (perfmon) -- there are some in the .NET CLR memory object that may be helpful.
Because the Framework allocates much more memory than it needs to run an application when it's loaded into the runtime, this may go some way to explaining the descrepancy. For instance, ANTS Profiler Service typically uses 10MB of memory even though it is only a few lines of 100% managed-code.