Taking ReSharper out of process – ReSharper performance series

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.

Conclusion

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.

This entry was posted in How-To's and tagged , , , , , , . Bookmark the permalink.

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

  1. Dude says:

    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” ?

    • 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:

    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.

    • 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:

      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.

  3. rosdi says:

    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.

      • rosdi says:

        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.

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

        • Dmitry Jemerov says:

          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:

            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:

            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:

            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:

          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).

  4. Jörgen Sigvardsson says:

    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!

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

  6. Stig Schmidt Nielsson says:

    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. Pingback: Dew Drop - May 30, 2018 (#2735) - Morning Dew

  8. Warren Rumak says:

    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?

    https://blogs.msdn.microsoft.com/visualstudio/2018/05/16/improving-the-responsiveness-of-critical-scenarios-by-updating-auto-load-behavior-for-extensions/

  9. Vasili Puchko says:

    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. 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:

    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:

    “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.

Leave a Reply

Your email address will not be published. Required fields are marked *