Out of memory issues

Hi there,

ReSharper (especially R# C++) is a fantastic product and helps me a lot during my day to day work.

We have quite a big code base at work (~ 500K LoC) in C++ and R# has serious issues to do its work without slowing me down.

Some of our code files are quite big and if I do a lot of refactoring and switching between multiple large code files, R# just swallows a huge amount of memory before doing GC and halting the whole IDE for 2-5 seconds.
Sometimes R# consumes > 2GB of memory and if that happens, the whole IDE becomes unusable and I can't even compile anymore because Visual Studio(32 bit process) cannot allocate any more memory I guess.

I known that our code files can be a bit messy so that might be one factor of the whole issue but I cannot change this right now.

Is it possible to solve this problem on your side?
I don't know much about extension development for Visual Studio but maybe you could spawn separate (64 bit) processes for the main parts of R# and only keep managing parts in the extension itself to solve the memory issue?
From what I can see after some quick Google searches there are a few developers having these issues.

I can imagine that my suggested solution would require quite a lot of time to implement so I only would like to know if this might be a solution for the future.

14 comments
Comment actions Permalink

Hello Torben,

Thanks for the kind words!

Moving ReSharper out of process is in the works. We already did this with the Rider IDE (which is IntelliJ frontend with ReSharper as an out-of-process backend), but moving ReSharper out of Visual Studio is much more involved. We don't have a timeline for this change, hopefully early next year.

There are several ways to reduce memory usage at the moment:

1) You can exclude unneeded code in your solution from indexing via "Third-Party Code" options page (see https://www.jetbrains.com/help/resharper/Reference_Options_Code_Editing_Third_Party_Code.html).

2) Switch to Visual Studio 2017 if you haven't already. VS2017 provides a new API for reading project properties, which allows to not load the entire project model in memory on the VS side.

3) To reduce memory usage during debugging, try  /Debug:fastlink. Release notes for VS 15.7 state that "Debugging large solutions with /Debug:fastlink PDBs is more robust. Changes in the PDB lead to reduced latency and a 30% reduction in heap memory consumption in the VS Debugger.".

In any case, we would be interested to take a look at the memory snapshot if you can take one when memory usage is high - there's always a possibility of a memory leak or something else going on. The instructions are at https://resharper-support.jetbrains.com/hc/en-us/articles/115000265844-Collect-memory-snapshot-in-Visual-Studio, but note that a memory snapshot might contain some confidential data, since it's basically a dump of all managed memory. In our own tests memory usage on the LLVM+clang+clang-tools solution is OK (in VS2017), and on Unreal Engine 4 is acceptable, so it would be interesting what's causing excessive memory usage on your solution - 500K LOC is not a lot.

Thanks!

0
Comment actions Permalink

Hi Igor,

thanks for you reply, I'll report back later. Quite busy here at the moment

0
Comment actions Permalink

Igor Akhmetov, what is the state of this feature?

Resharper's memory usage on large solutions is getting more and more problematic. For example VisualAssistX offers this for quite a while now, but Resharper's has better features in my mind, but I run more and more into cases where I have to restart my VS a couple of times a day to get the memory usage under control.

0
Comment actions Permalink

Geert,

Please send us a memory snapshot for investigation if memory usage is a problem for you.

We hope out-of-process ReSharper will be available in 2020.2 or 2020.3. If you are able to switch from Visual Studio, we'll also start the public preview of Rider C++ in a month or so, which runs ReSharper in a separate process.

0
Comment actions Permalink

Igor Akhmetov, thanks for the info.

Moving to another IDE is not not in the cards at the moment.
Next time I have memory issues again I'll create a snapshot and get back to you.

0
Comment actions Permalink

Igor Akhmetov, report send with id RSRP-478018 (https://youtrack.jetbrains.com/issue/RSRP-478018)

and another one captured during source file parsing:

https://youtrack.jetbrains.com/issue/RSRP-478021

0
Comment actions Permalink

I agree this is serious and expensive for us (time consuming). I finally had to disable reharper because VS crashes way to often (our solution contains around 200 projects). If you have cache issues maybe that's where you should focus? Sadly emptying caches did not help me yesterday.. crashes came back kind of straight away. The computer are healthy (followed your official steps for troubleshooting this, including doing the system scan/restore)...

The typical event log output (it's in Swedish):

Tillämpningsprogram: devenv.exe
Framework-version: v4.0.30319
Beskrivning: Processen avslutades på grund av ett ohanterat undantag.
Undantagsinformation: System.OutOfMemoryException
vid System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].AwaitUnsafeOnCompleted[[System.Runtime.CompilerServices.ConfiguredTaskAwaitable+ConfiguredTaskAwaiter, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[Microsoft.CodeAnalysis.SolutionCrawler.SolutionCrawlerRegistrationService+WorkCoordinator+IncrementalAnalyzerProcessor+<>c__DisplayClass34_1`1+<<RunAnalyzersAsync>b__0>d[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], Microsoft.CodeAnalysis.Features, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]](ConfiguredTaskAwaiter ByRef, <<RunAnalyzersAsync>b__0>d<System.__Canon> ByRef)
vid System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_1(System.Object)
vid System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)
vid System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
vid System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
vid System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
vid System.Threading.ThreadPoolWorkQueue.Dispatch()
vid System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

0
Comment actions Permalink

Aron, please see my second message on the thread and send us a memory snapshot for investigation if you can.

0
Comment actions Permalink

Igor Akhmetov, is there any ETA in getting Resharper to run in an out-of-process process and bypass VS's 32-bit limitations? Last you mentioned something in this area was that it could be early 2019. We're 1 year further away and still no out-of-process solution in sight for VS? (at least the EAP versions don't have it yet).

0
Comment actions Permalink

Geert Bleyen, the latest official update is https://blog.jetbrains.com/dotnet/2020/02/24/update-running-resharper-process/, ETA is "hopefully we have something to show this year". Next week we're opening free public preview of "Rider for Unreal Engine". It has "Unreal Engine" in name, but basically it just runs ReSharper C++ out of process and should work for many other projects. Give it a try if you have a chance, it should result in massive performance improvements compared to VS + ReSharper.

0
Comment actions Permalink

Igor Akhmetov, thanks for the info. As our solution consist out of 120+ VS projects, trying it our in Rider will be difficult :).

Either way, good to hear this is still being worked on and eagerly awaiting the results of all that work.

0
Comment actions Permalink

Igor Akhmetov :: Sorry I just realized I'm in the wrong thread :: I've got issues with R#. However if they're related please let me know.

0
Comment actions Permalink

Geert Bleyen, if R++ can open your solution then so should Rider, and even user experience should be very similar if you use the same keymap in both IDEs

Aron, probably the usual memory pressure situation where there's not enough memory in the Visual Studio process for both Roslyn and ReSharper. Please send us a memory snapshot to confirm this if you can. If you have a chance do try Rider, it won't have that kind of performance issues.

0
Comment actions Permalink

Geert Bleyen, public preview of Rider C++ is now open - https://www.jetbrains.com/lp/rider-unreal/. It has "Unreal Engine" in its name, but can be used for general C++ development. We'd appreciate if you could try it on your solution when you have a chance. Thanks!

0

Please sign in to leave a comment.