Update: ReSharper 5.0 Memory Consumption in Visual Studio 2010

After some discussions with a friend (thank you, Steve!) I have conducted further tests. This time I ran my little experiment with just Visual Studio 2010 and no add-in, extension or whatever installed. Just as it comes out of the box. To measure the memory consumption I used VMMap from SysInternals (owned by Microsoft).

VMMap also displays metrics for the Managed Heap. That’s the place where the objects are stored that are created when you instantiate objects using “new” within your C# code (other languages may use other keywords). Again I used the same solution as in my previous post on the subject, and I followed the same actions: Close Solution, Open Solution, Record current memory consumption.

This time I did 30 runs. First I did this for just VS 2010 without any add-in, extension, etc. Then I repeated the test but this time I had ReSharper installed. The memory I recorded was the “Committed Memory” as per VMMap. The results of my measurements is shown in the following graph:

For this test I used ReSharper 5.0.1659.36. Visual Studio 2010 was the latest and greatest according to Windows Update. VMMap was version 2.62. Be aware that for this test no other add-in, extension, etc. was loaded at any time. The only difference between the runs was that for the second run R# was installed while it wasn’t for the first run.

On a side note: You may wonder why closing and opening matters. Well, my preferred source control plug-in is AnkhSVN. And most of the time is does a great job. Except when it comes to service references. We version these as well but AnkhSVN doesn’t seem to pick up changes in these files reliably. Therefore when we need to update service references – which can happen a lot when we are implementing a new service library – then we use a different tool to commit the change set. Typically we use TortoiseSVN for that. And to make sure that all changes, including solution and project files, are properly saved and picked up, we close the solution file. After the commit we then re-open the solution and continue coding.

Your style of working is most certainly different so this scenario may not apply. For example, on days that I can fully spend on coding I typically commit 10 or more times a day.

At the end of the second test run I then looked at the details for where the managed memory is consumed. It looks as if the memory that doesn’t get freed is listed under Garbage Collector (GC). It appears as if the GC cannot free up some big chunks of memory. This could be application domains that cannot be free because there is still a reference, or large caches or something like that. Here is the screenshot I took from VMMap at the end of the second test run:

What to make of all of this? If you have small solutions, plenty of memory (and there are tricks to tell Visual Studio to use more than 2 GB), don’t need/want to close the solution as often as I do, I’m sure that you will be unaffected by this. I haven’t checked yet how the memory consumption evolves over time under normal workload. I’ll monitor this as well and see whether there is more to discover.