Question

I’ve been trying to compare the memory footprint between a VB6 application and .Net application. Trying to determine what’s the average difference between the two.

The .Net code is for the most part a direct translation of the VB6 and for the most part has the same instructions as they would be programmed in C#. So while it’s an apple to oranges comparison, it’s a comparison on programs that are functionally (if not logically) equivalent.

I’ve been using Process Explorer to help me determine the usage of memory of the applications, however there are a few areas that have left me perplexed:

1. I’ve been trying to determine the overall memory consumption. Which of the Process Memory columns should I be using. So far I’ve been looking at the Working Set ones.
2. For comparing the size of DLL’s within an application PExplorer shows Size, WS Total and other WS counters, how can these be interpreted? And why is Size so different from WS Total, shouldn’t these be the same?

So far I’ve gathered that WS Total includes both WS Private and WS Shareable. So using WS Total only can be a deceptive measure. I’ve also read from questions such as .Net exe memory footprint that the .Net working set is usually larger than it should be. Would instantiating the process in a memory starved environment, say a VM with 128 MB reduce the working set size to it’s minimum?

Any help or insight would be greatly appreciated.

Answer 1

There is a good essay on this by Mark Russinovich.

You can manually reduce your app’s working set by using the Win32 API call SetProcessWorkingSetSize(GetCurrentProcess(), -1, -1). This is what Windows will do anyway when the system runs low on memory, but controlling when this happens yourself lets you strip your .NET app’s working set to its minimum size for investigation purposes.