Investigate high memory load without providing memory dump


First of all I'd like to highlight that Resharper C++ is really an amazing product just like R# is for C#. It provides not only tons of great features it also helps you to constantly improve your code base with modern C++ features.

Unfortunately, as you know from many other customers, memory consumption is a big problem with Resharper C++. We have a huge C++ codebase with a lot of legacy code. Lately I need to restart my Visual Studio in a ~1-2hrs rhythm because the memory in Resharper C++ is constantly growing. When it hits ~1-1.5GB Visual Studio becomes unresponsive and unusable. Symptoms  are similar as described here. I'd love to provide a memory dump for improving the situation but unfortunately our code base is highly confidential and a memory dump would include information I am not allowed to provide. 

Is there maybe a possibility to find out on my own what could cause this issues? Maybe it is caused by some dedicated project or library (e.g. boost). I already tried to analyze the situation in the past weeks with DotMemory and could see that there is a huge amount of certain objects. Do you maybe have further tools/scripts that would allow me to dig deeper and find the potential root cause? 

I will try to repeat my tests and provide at least some object statistics. I'd be happy to share further details based on some anonymized data if you have better tools. Maybe the "Internal Options" already can provide some more details. 

My Environment: 
Visual Studio 2017 15.8.2
Windows 10 Pro 1803 64bit 
Resharper, Resharper C++, dotCover, dotMemory, dotTrace 2018.2

Kind Regards


Hello Daniel,

Thanks for the kind words!

If your project is large, chances are you can ignore some parts of the codebase. In this case the easiest approach to reducing memory consumption is to exclude these parts from indexing via the "Third-Party Code" options page ( You'll likely need to clear caches and reopen the solution to purge extra data from the cache though.

Unfortunately, dotMemory cannot yet export a workspace without sensitive data, we've created a feature request for this - If this is an option for you, JetBrains can sign an NDA with your company so you can share the memory snapshot. If not, could you please send us a screenshot of the "Dominators" tab from dotMemory on a snapshot taken when you experience memory pressure? This data should not contain confidential info. If you prefer, you can reach me directly at igor.akhmetov _at_

We are also working on moving ReSharper out of the Visual Studio process. Although we don't have a timeline for this change yet, we hope it will help with high memory usage.




Hello Igor. 

Thanks for the response and entering a feature request for the future. Below you find a screenshot of a Before-After comparison on the Dominators tab. I also have some more details now regarding this topic: 

  • Overall Visual Studio is already hitting the 32bit Memory Edge (3.5GB) whereas ~1GB is consumed by Resharper. 
  • While I am working and typing in the code editor I can actively see with every small change the memory increases (via Resharper Memory Info in the Status Bar).
  • Typically my solution starts at 800-900MB after opening, then grows up to 1.5-1.6GB as I work on it. 
  • Over time this increase becomes faster until it hits a almost constant overload on every change. Then I need to restart VS.
  • As soon the Garbage Collector kicks in, the whole Visual Studio gets stuck (likely due to some more agressive GC when OutOfMemory is reached). 

In the screenshot I tried to catch a state directly after GC and one when it hits the ~1.5GB area. The Dump does not directly reflect the Memory Indicator. 

I will try to also to a dotTrace profiling to check which code is executed during this memory growth. 



Thanks a lot! It's hard to say whether there's a memory leak here, but the data looks plausible even without a leak. R++ stores data in memory for a number of open documents, and it seems that in this case this number is too high. We'll experiment with lowering these limits in 2018.3, I'll ping this thread when there's an EAP build to try.


I was also able to capture a timeline trace while the memory was almost constantly at its edge and causing constant freezes every few seconds of scrolling and typing. Here already a sneak-peek of the view. You can see the UI freezes and also the CPU peaks during this phase. 


I scanned the contents of the trace file and unfortunately it also seems to contain confidential data so I cannot provide it. but I could provide some more detailed views if this helps for finding potential memory allocators during this phase.

If you make the limits available via some (internal) options I could in worst case play with the values to check what limits would fit for us. 


Unfortunately GC pauses tend to get very slow with high memory usage in a 32-bit process. A timeline trace is great for determining the causes of hangs (e.g. purple segments near the top represent UI stalls, if you click on one you should see on the left that 100% is spent on GC), but unfortunately it does not have the full memory distribution, only memory traffic.

It looks like R++ is unusable on your solution at the moment, sorry about that. Please disable it for now, we'll try to do some tweaks in 2018.3 - would appreciate if you could try it out later. We also aim to offer at least one of the two possible solutions to the memory problem in Visual Studio - running R++ out-of-process either from Visual Studio or from Rider.


Unfortunately the situation did not improve at all in 2018.3. Not only that, but the problems now also appear in .net solutions. I tested everything now for a while and I am constantly suffering of high memory usage causing VS to become unresponsive. Did you guys maybe add some hidden settings where I could try tuning the cache to load less from the disk? 


Would it be possible for us to have a quick TeamViewer session? I'd be interested to take a look at the distribution of memory on a memory snapshot with high memory usage from 2018.3. 


Please sign in to leave a comment.