Visual Studio with ReSharper is slow

We do our best in terms of ReSharper performance, however there are some known and unknown cases where ReSharper can slow down Visual Studio.

Below is a check list that will help you troubleshoot, work around or fix the performance issues with ReSharper.

  1. First of all, make sure that the slowdown is caused by ReSharper, as opposed to a different part of your development environment. To do that, simply suspend ReSharper as described here and check if performance issues are still present. If performance improves noticeably when ReSharper is disabled, proceed to the following steps.
  2. Make sure that ReSharper system requirements are met. Please check your environment against the current system requirements. In addition, using more RAM and a Solid State Drive (SSD) instead of HDD is known to help a lot in improving Visual Studio performance with ReSharper.
  3. Review Visual Studio and ReSharper configuration. For a long list of Visual Studio and ReSharper settings that can be modified in order to improve performance, see Speeding Up ReSharper (and Visual Studio). For a maximum impact with minimum configuration changes, try the following short list:
    • Make sure that ReSharper's Solution-Wide Analysis (SWA) is turned off ("ReSharper | Options | Code Inspection | Settings | Enable solution-wide analysis" should be off).
    • If you're using Git command line or an external Git client, or if you're using a VCS other than Git, or you're working on a solution that's not under version control, please turn off Visual Studio's Git integration ("Tools | Options | Source Control | Current source control plug-in", set to "None", then restart Visual Studio)
    • Review Visual Studio settings listed under "Configuring Visual Studio preferences" in Speeding Up ReSharper (and Visual Studio)
  4. Take a Visual Studio performance snapshot and send it to JetBrains. If completing the steps outlined above didn't help improve performance, please capture a performance snapshot with ReSharper's bundled profiler, and provide it to JetBrains. We will be able to investigate the performance issue and provide specific recommendations for you. To do this, please follow steps described in How to collect a performance snapshot.

What is possible with Coderush should be possible with R#. So they must wake up and speed-up their costly tool.


If they were going to wake up and make their product better, they would have done it already.  They have no incentive to make their product better as long as they keep receiving money every year.  Complaints alone don't cost them any money.


At my wits end with this.  I'm now in the process of uninstalling Resharper and we won't be renewing our subscription for any of our team.

Using the latest version and trying to edit a medium sized javascript file.  Resharper just freezes Visual Studio after almost EVERY operation.  

Undo a typing error.  5 second freeze.  Type a closing brace on a 'for' loop.  10 second freeze while it formats the 10 lines of code within the loop.  Undo the dodgy Resharper formatting of a jquery attach event.  30 second delay.

Absolute joke.  It's at a stage now where Resharper is costing me more time than it's saving.  Time to ditch.




Can we just all agree that this product should be resigned to be open source and let the community fix the issues. It’s obvious no one can use this tool anymore with the complexity on VS. we as a community can fix the issues where JetBrains has failed and/or doesn’t care.


Hi Guys,

It is not perfect, but I do not see anywhere near the issues being mentioned here.  I am using VS 2019 Pro and R#  on Win 10, all on the latest versions.  I'll admit my projects are not big as in Microsoft Windows source kind of big, but some of them are not small.  I guess the fact that we use C# exclusively could make some difference.  The only thing we disable (which we would do with or without R#) is whole solution analysis.  The biggest lag we see is when we load the solution, and we have seen a problem with freezing completely when we load straight into a solution instead of loading it after we have started VS.  Other than that, we don't see any real performance issues.

I am not saying this to argue that all of the people having issues are imagining it, but I do wonder if 1) it might not be 100% R# causing the issues and/or 2) there are some software/hardware configurations that do much worse than others.  For instance, I know that having the source code stored off machine can murder R#'s performance.  Or at least it use to.  Finally, maybe it is some specific languages that have the issues? 

There is no way to test every possible configuration to see if there is an issue, so I am sure it really helps if folks send the snapshot files.

I do think it would be prudent for them to take a broad look at the different parts of R# and start integrating Roslyn where it makes sense - i.e. start a slow migration.  However, I am not sure this would resolve anything.  If not, it would reduce the number of possible culprits.

Anyhow, I guess what made me pop on here to make a comment is that it strikes me how many people are still having issues while our experience is so much better.  It is confusing to say the least.


I have a top of the line computer, it is 100% R# causing the issue.

You are the first person I have heard that does not have performance issues. Count yourself lucky.  

I guess the most frustrating thing is, JetBrains support, always asking for a files, then, most likely not even looking at them telling you to turn everything off.  It's hilarious really. 



I run on a VM hosted on SSDs.  We code exclusively in C# and all of us have the performance issues.  I have stopped our auto renewal because the performance hit is too great.  Opening solutions takes minutes, then copying/pasting code occasionally takes a very long time, sometimes typing a comment will freeze it.  It's lots of random times where our computers will freeze but it happened enough to make us stop using it.


I have to agree with others, it's R#. On and off, with no other changes, is like night and day.


I am not saying that R# is not involved, but i am saying that it is in combination with other factors.  If anyone can have a decent experience, then there has to be another factor.  My machine is not a maxed out workstation.  It is just a decent laptop with 32GB of memory running on an SSD.  I do consider myself lucky based on what I have been reading, but I also cannot be the only one.  Not by a long shot. If everyone (or even significant minority) were having these kinds of issues, then they would have trouble staying in business.

I am not trying to argue that anyone should stick with it.  Whatever the reason is, if it is not working for you then it is not working for you - whether that is because of performance, cost, or whatever.  I am trying to point out however, that it is very likely a combination of factors that R# has working with.  I can certainly understand if it is not worth the frustration to keep messing with it.


A hello world application always runs fast. Once you step away from simple solutions there hundreds of exceptions being thrown. 1% of the users working fine does not constitute a reliable test base. You throw a cross platform set up project in there and it is a dead crawl.


Not sure but it's probably heavily dependant upon several factors such as the complexity of your project (in terms of cyclomatic metrics), namespaces/assemblies dependencies, number of hints/warnings in your opened files, etc. If R# runs fast, it probably means your code is quite clean and well-organized :)

Wish the app would be open-sourced but I definitely doubt it will ever happen. 


Interesting that you use a childish insult with clean code. You no doubt, have not worked on a solution outside of a web site with a few class libraries or you would understand how simpleton your comment is.

I personally think you’re a JetBrains employee trying save a flawed application. The simple fact, is once you get beyond a simple project and have a real solution that is cross platform ( 5+ projects ), it crawls and crashes. I can also, see based on your response you have not actually done this, otherwise you would notice exceptions. Keep trolling people having real issues, your just adding to our frustration.


Not wanting to get competitors involved here but I have been playing with CodeRush. I don't think it has the same feature set as R#, and I do notice little helpers missing (maybe they are a configuration, I don't know yet) but what I do notice is that I don't have any of the performance problems with R#. Same laptop, same solutions, no lags. It clearly is possible to provide above and beyond what VS does out the box without killing the "experience" in the process. Question is why aren't JetBrains doing it?


Nick5454, are you talking to me? Read my message again and please indicate where I use an insult about clean code. If the code is simple and clean according to *their* engine constraints, R# will be probably faster because it does not have to analyze all the stuff it is supposed to analyze in a larger project where things are often messy with large classes, and so on. Try to put a large class with 2000 lines and tons of R# hints and it will be slow like hell. That's my point but it's probably too advanced for you. 

I am working with a solution with several projects, more than yours and R# is -not- satisfying on a daily basis in these legacy projects. Read all my messages again before talking about trolling. I have been complaining for years about R#. Now you can go away with your frustration and lack of readability skills, I am not a JB employee but I would definitely not hire you either.

Edited by KD

I'm having lots of issues as-well. So much so that Visual Studio itself is even telling me Resharper is being unresponsive:

This is on a brand new Microsoft Surface Book 2:
i7-8650U, 16GB Ram, 256GB SSD.

Edited by J Bastnagel

I had a friendly discussion with Jetbrains employees on some conference. The issue is that reshaper is using its own analysis, but there is also a roslyn one built in the visual studio. The Roslyn one cannot be turned off so there are two analysis running in parallel.... at least that was my understanding of that. CodeRush will probably use the roslyn one as well. Well we have a lot of issues with resharper performance as well in reasonably big solutions (10-100 projects).


If Jetbrains knew this when they started then they also were fully aware in almost any production app this slowness would appear.  It would stand to reason they would try to use the Roslyn engine.  A quick internet search found that another third party tool has integrated with Roslyn and it's called SolarLint.  Even if Jetbrains beat Roslyn to market, their code should be refactored to integrate with Roslyn and possibly even give an option if that would mean feature loss so it's up to each developer to decide if they prefer speed over features.  I've found it's not so much the number of projects as it is the number of classes.  We had issues with Resharper in solutions that only had 2-3 projects, but each project might have hundreds of classes with several hundred to thousands of lines of code.  We also cancelled our subscription to Resharper due to the performance issues.  There are only a handful of features I miss, but VS2019 has most everything I used.  With each successive version of Visual Studio, the native offerings got better and better until it was no longer justifiable to bear with the slowness of Resharper. 


It's driving me crazy. I hotkeyed "Suspend ReSharper" and the ENTIRE IDE is 10x faster when I suspend ReSharper. It's insane. I get microstutters all the time. It takes ages for IntelliSense/AutoComplete to pop up sometimes. I have to periodically clear the cache in order to get somewhat acceptable performance.


Please sign in to leave a comment.

Have more questions?

Submit a request