Taking ReSharper out of process – ReSharper performance series

Maarten Balliauw

In the previous post of our ReSharper performance series, we looked at Visual Studio and ReSharper complexity and history, and determined that one of the reasons for degraded performance lies in Visual Studio being a 32-bit process. In this post, we will look at what can be done to overcome that limitation.

In this series:

Let’s dive in!

Roslyn and ReSharper

We’ve looked at the 32-bit process limitations, and figured out there is only so much memory that can be consumed. So one might ask: why is JetBrains still building their own language engine with ReSharper? Why not just use Roslyn so that there is only one engine in memory instead of two? And as a bonus, ReSharper development may go quicker?

There are a number of reasons for not doing this, as explained in our ReSharper and Roslyn Q&A. A better question would be the following: is it worth replacing a well-oiled engine just to work around the limited 32-bit working set? And how long would it be before that replacement also runs against the boundaries? Surely there are better ways…

Microservices! (in the form of child processes)

How can one go beyond this hard limitation in available memory? As with everything, the answer is microservices. Visual Studio is gradually transitioning into a process with many child processes, where every one of those child processes can consume the amount of memory it needs.

Child processes

This architecture has several advantages: each child process has its own thread pool and can be run on different CPU cores by the operating system. Each child process also has its own memory space and its own garbage collector.

We use the same approach in Rider, our cross-platform .NET IDE, where the IDE is just the UI and a host process, and a lot of the heavy lifting happens in the child processes that are spawned, and this works wonders for performance.

Running multiple processes does present some other challenges. How do you keep them in sync? Do all keystrokes in the editor have to be processed? When we type a class name and then remove it again, does it have to exist in both processes? The reactive distributed communication protocol we use in Rider may be the answer to these questions.

JetBrains is investigating making ReSharper a child process of Visual Studio, instead of being part of the main process.

Async loading of the ReSharper VSPackage

Next to making ReSharper run its own process, we can improve loading the bits that have to remain in the Visual Studio process. We’ll still be able to render menu’s, show refactoring dialogs and keep track of what is happening in the editor.

Visual Studio is really just the Visual Studio Shell, which loads a number of VSPackage instances that contain language features and specific tooling to make it an IDE. Pretty much every checkbox in the Visual Studio installer represents such VSPackage, and ReSharper is another VSPackage instance that can be loaded.

Visual Studio performs delay loading when a package is only needed in certain contexts. Newer versions of Visual Studio allow asynchronous loading of a VSPackage as well, moving the work to a background thread.

JetBrains is investigating loading ReSharper as an asynchronous VSPackage.


In this post, we have looked at one of the ways to make ReSharper performance better: taking it out of process. This brings many benefits: both Visual Studio and ReSharper run in their own process, have their own thread pool, and their own memory space. In addition to that, we are investigating async loading of ReSharper in Visual Studio.

None of these solutions will be the silver bullet by themselves, though. There are other areas that can be improved, and we will look at those in our next blog post!

If you are experiencing performance issues, make sure to check the Performance guide for Visual Studio (ReSharper 2017.3+) as well as our KB article Speeding up ReSharper (and Visual Studio). If you have a specific performance issue you can reproduce, we’d appreciate if you could collect a performance snapshot and send it over.

Comments below can no longer be edited.

41 Responses to Taking ReSharper out of process – ReSharper performance series

  1. Dude says:

    May 29, 2018

    Do you have a rough estimation about how long that would take to implement ? Or is this statement just to say, “don’t worry we know this great product is dying and will try to do something about it” ?

    • Maarten Balliauw says:

      May 29, 2018

      As soon as possible. This specific one may take a bit longer (it’s essentially rewriting all of the VS integration), but as we will see in tomorrow’s post, many other things will be improved faster.

  2. tobi says:

    May 29, 2018

    If you’re looking for feedback to this: I do not care much about startup performance. I think most devs have learned to keep their large solutions open. Not even shut down the PC but put it to sleep over night.

    Interaction performance is what’s important.

    • Maarten Balliauw says:

      May 29, 2018

      Both are (and in fact are linked together as well, .NET has some JITing to do on startup that helps later on… more on that tomorrow)

    • Marco says:

      May 29, 2018

      A use case that comes up often for me is that, although I keep Visual Studio open, I tend to reload the solution several times per day when I switch branches, stash changes or rebase interactively. Solution-load speed affects all of these operations as well.

    • Wolfgang Kinner says:

      November 14, 2018

      Of course interaction while working is more important, but startup can be very important too, and not be solved by keeping big solutions open. I have been working in huge Projects, where you easily have 10 to hundred Solutions, and while you are new and trying to find, or bugfixing you easily come into situations, where you need to toggle through many solutions, especially as a new developer in that team. So something like delayed/asynchrous load could help.

  3. rosdi says:

    May 29, 2018

    Rider seems to be using the same UI as IntelliJ… ugh!! I tried WebStorm once and i tried to like it but my eyes just couldn’t stand it.

    • Maarten Balliauw says:

      May 29, 2018

      Could try the dark theme or the material theme – https://plugins.jetbrains.com/plugin/8006-material-theme-ui

      • rosdi says:

        May 29, 2018

        Thanks for replying my out of topic whining…

        I did try the dark and also the material theme… it made the IDE even uglier… seriously… just put WebStorm with dark theme side by side with VS Studio dark theme… or compare it against Visual Studio Code…

        Seriously… just do that.

        I spent more time trying to configure the theme than actually being productive, I ended up uninstalling WebStorm…. be gone!

        Realising Rider looks just like WebStorm (theme wise), I do not have any interest whatsoever to try it…

        Hope you can forward my whining to the GUI department and have it revamped… until then… Visual Studio and Visual Studio Code for me.

        • Maarten Balliauw says:

          May 29, 2018

          Will definitely pass it on. Thanks again for taking the time to comment!

        • Dmitry Jemerov says:

          May 29, 2018

          We’d really appreciate it if you could articulate your feedback in more detail than “just do that”. Just did that, and I’m not sure what exactly I am supposed to see other than two products that look different. Are you unhappy with our choice of colors? Fonts? Icons? UI control layout? Something else?

          • Jörgen Sigvardsson says:

            May 29, 2018

            Here are my two cents (for CLion, but I think it applies to all of your standalone IDEs). My biggest beef (which is actually pretty small) is the contrast between UI elements. The contrast isn’t sharp enough, if you understand what I mean. I find it harder see where one UI elements ends and another starts. That’s less of a problem for me in Visual Studio. I can’t be anymore specific than that, sorry. I’m a software architect, and not a UX champion. 🙂

          • rosdi says:

            May 30, 2018

            Sorry for that… now you forced me rethink it I would say not enough contrast, not enough sharpness (especially the fonts), too many colors (icons) which makes it hard to the eyes…

            Take a look at VS dark theme, the colors are uniform… good contrast, leading to professional polished look…

            Sorry I do not know how to be preciser than that…

          • Penley says:

            June 6, 2018

            Would be awesome if we have an alternative “Color Identifiers” syntax highlighting. Bright cyan and pink on dark theme is… kind of hard on my eyes.

        • Jörgen Sigvardsson says:

          May 29, 2018

          Dude, you should look at the code you’re writing, and less on the UI. Sure, it’s not what you’re used to, but it’s not that bad. I have no problems using any of the intellij-based products. I thought CLion was awesome (only intellij based IDE I’ve used in years).

          • rosdi says:

            May 30, 2018

            I will be starting at it for hours… everyday… it is important to me.

  4. Jörgen Sigvardsson says:

    May 29, 2018

    I’m so happy that you are addressing performance. I have this giant solution with 165 projects in it, and it does get on my nerves from time to time. I love the functionality that ReSharper provides, and I would love to keep on using it!

    • Maarten Balliauw says:

      May 29, 2018

      Awesome! Thanks so much, Jörgen! And when you have any issues, do let us know.

  5. The Morning Brew - Chris Alcock » The Morning Brew #2594 says:

    May 30, 2018

    […] Taking ReSharper out of process – ReSharper performance series – Maarten Balliauw […]

  6. Stig Schmidt Nielsson says:

    May 30, 2018

    So if you are taking Resharper out of process, then it should be pretty easy to integrate with Visual Studio Code just like the Omnisharp is doing today?

  7. Dew Drop - May 30, 2018 (#2735) - Morning Dew says:

    May 30, 2018

    […] Taking ReSharper out of process – ReSharper performance series (Maarten Balliauw) […]

  8. Warren Rumak says:

    May 30, 2018

    Isn’t the async VSPackage route going to be required no matter what, given that Microsoft recently announced the deprecation and eventual removal of auto-loading synchronous extensions?


    • Maarten Balliauw says:

      May 30, 2018

      Yes, for newer VS. But since we also support older VS we are looking in the asynchronous direction there, too.

  9. Vasili Puchko says:

    May 31, 2018

    I’ve been an active user and proponent of R# for very long period of time. But things started to change in recent years with wider adoption of Roslyn-based extensions for VS. You tried to explain why you don’t want to adopt Roslyn and work with MS team to do required adjustments. I understand that at that time, in 2014, Roslyn wasn’t mature and R# was on a leading position considering available refactorings and useful features. So from business point of view it was better to put a line in between and stick with existing approach.
    For years later Roslyn became mature and got wider adoption and many-many features contributed by MS and opensource developers. R# on the other hand is stagnating and collapsing under the technical debt. Many old decisions are becoming roadblockers – the idea to write your own JS/TS engine lead to having a lot of issuses and wasn’t able to cope with the speed of evolution of JS/TS. Quite similar situation is with the C#. Roslyn evolves very fast and R# is struggling to catch-up and from being a useful helper it became the thing which slows VS (under certain conditions).
    Since 2016 each year I did a trial – check if I can survive by disabling R# and use only Roslyn with opensource extensions. The situation was quite bad in 2016, it was still ugly in 2017 but in 2018 with introduction of “Enable Navigation to Decompiled Sources” setting in VS based on Roslyn they’ve finally got me – overall experience is already on the R# level and it’s applicable not to VS but also for VS Code as well. Thank you R# team for such a good product which helped me to develop multiple products and I wish you best of luck in the future.

  10. Andrea Angella says:

    June 1, 2018

    I am so pleased to see you are actively working on improving performance and moving R# out of process. Hoppy to test an early relase of this. Please deliver it as quickly ad possible. I am seriously struggling a lot with perfarmqnce in Visual Studio on a daily basis and R# is always mentioned as the cause of it. I love R# and I want to keep using it but I see myself moving away from it if the performances comtinues to deteriorate. It’s affecting my productivity.. Thanks

  11. Phil Lee says:

    June 2, 2018

    At last some news on taking R# out of process. Can’t wait to see it. If it works and doesn’t slow VS too much I might start using R# again. I gave up with R# about 2 months ago because it’s so slow on our 180 project solution. I now code with VS and occasionally load up the solution in Rider to look for issues.

  12. Mark Adamson says:

    June 16, 2018

    “If we run AOT compilation as part of installing ReSharper, installation would take longer to run and would require running with elevated privileges, which many of our customers don’t allow.”

    It would be great if you provided this as an option when installing. Our dev VMs are built once with no further option for updates by our IT guy so he would be fine with requiring admin rights as he needs them to install VS.

    • Maarten Balliauw says:

      June 18, 2018

      Thanks Mark!

    • Jeff Chen says:

      June 29, 2018

      As a superuser I would like an option for this AOT to optimise performance.

  13. Roland says:

    November 14, 2018

    Any updates on this?

    What about AOT, can we manually do this?

    • Maarten Balliauw says:

      November 15, 2018

      Work in progress, next version will come with a number of fixes.

  14. Mihail says:

    January 16, 2019

    Any news on resharper out of process?

    • Maarten Balliauw says:

      January 16, 2019

      It is an ongoing effort, nothing to announce at this time.

  15. Stig Nielsson says:

    March 27, 2019

    Any news on the out of process thing now that VS 2019 is soon coming out.

    • Maarten Balliauw says:

      March 27, 2019

      Out of process is not ready yet for prime time, however a bunch of other fixes went into VS2019 (among them async loading of ReSharper starting with the next EAP build).

  16. FrustratedEngineer says:

    June 11, 2019

    Still waiting…it’s been a year…

    Current product is unusable when the sln contains 75+ projects, even on fast hardware.

  17. Rodney Lane says:

    July 17, 2019

    Its July 2019

    Loaded up Resharper 2019.3 and let it loose on my solution.

    Solution has 128 projects – large yes – but necessary.

    Computer has 32 GB Ram, Core i7 quad core hyper threaded, with 1TB SSD.

    Visual Studio 2019 crashes to desktop after solution rebuild when Resharper is enabled. (ran out of memory)

    Now Disabling Resharper as I cannot work with it enabled.

    No out of process update on the horizon any time soon from what I have read.

    Apart from today – haven’t used resharper for over 9 months now due to it killing visual studio with large solutions. Thought that maybe with VS 2019 the resharper processes would be out of process.

    Subscription renewal due in 2 Months – Renewing? – Probably not – cant use the tool for what it is designed for so why bother maintaining the subscription – just a waste of money.

  18. Jan van Westland says:

    July 22, 2019

    .net 5 is coming soon. VS-Code will support .net 5. VS-code already is great nowadays but with this JB Rider will loose for sure from VS-code. Better build Resharper plugin for VS-Code. JB better get smart instead off stuborn or loose all business all together.……

  19. Kenny says:

    August 8, 2019

    This issue is costing me a lot of time. I keep testing new releases that promise less memory consumption, but invariably the 1+ gigabyte held by Resharper is too much for my team’s large project and OOM + major heap GC events destroy usability.

    This is a pure good, please fast-track it so I can get the rest of my team using the smarter tools… And so I can use them myself.


Subscribe to .NET Tools updates