How to measure the effect of properly reloading .NET collections before NGen?

There are many .NET assemblies in our application that have not yet been deployed using NGen scripts, so they are always in JITted mode at runtime.

Since our application is usually deployed on a terminal server, getting Windows to share binary images of code is probably more optimal than the current method, so I’m considering setting up base addresses and NGen'ning assemblies.

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

So far so good with listdlls Now I can see that none of our assemblies have been reinstalled at runtime.

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

What numbers should I look at and with which instrument to find the actual effect, if any?

For example, I know that the act of reloading our assemblies can lead to the fact that we use third-party assemblies that we use (for example, DevExpress components) so that they suddenly rebuild, and then all this is washed.

So where do I read, what numbers? For example, am I using the task manager working set? Private memory? fix size? free memory before and after?

Any tips?

+4
source share
2 answers

The only significant value for you is the private bytes of the process, which is the number of bytes allocated (no matter where) that are not shared between processes.

I cannot find the source, but at the same time .Net can also share (some) assemblies without being ngend.

Edit: I would also be interested in your findings on changing personal bytes with and without ngening.

+2
source

In fact, you no longer need to reinstall Vista or later. See my answer to another post that links to this Microsoft blog . The blog explains: "with ASLR, while the final location is random for each machine, it is the same for every process on the machine, which means that the moved data can be used for all processes."

The whole reboot process is a bit confusing, so this is welcome news!

+1
source

Source: https://habr.com/ru/post/1307674/


All Articles