How to measure the effect of correctly rebasing .NET assemblies before NGen?

Question

Our application has a lot of .NET assemblies, which up until now, has not been deployed with NGen-scripts, so they are always JITted at runtime.

Since our application is typically deployed to a terminal server, getting Windows to share binary images of the code is probably more optimal than the current way, so I'm looking at setting base addresses and NGen'ning the assemblies.

So I ran the program without NGen whatsoever, and used [listdlls from SysInternals][1] to find the size of each, which I then increased to the next class of size (ie. xxxx --> 10000). I then laid out a memory list for all our assemblies, and adjusted the base addresses of them all.

So far so good, with listdlls I can now see that none of our assemblies are rebased at runtime.

However, how can I measure how much memory is actually shared between two instances? Basically, let's say I start two instances of the program without having executed NGEN on the assemblies, and then after having executed NGEN, do it again.

What kind of numbers should I look at, and from which tool, in order to find the actual effect, if any?

For instance, I'm aware of the fact that the very act of rebasing our assemblies might move 3rd party assemblies we use (DevExpress components for instance) around so that they suddenly must rebase, and then the whole thing is a wash.

So, from where do I read which numbers? Like, do I use the working set of task manager? The private memory? commit size? free memory before and after?

Any advice?

Answer 1

The only meaningful value for you will be Private Bytes of a process which is the number of bytes allocated (regardless of where) that are not shareable between processes.

I can't find a source but afair current .Net can also share (some) assemblies without being ngend.

Edit: I would also be interested in your findings about the change of private bytes with and without ngening.