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.
154 comments
Comment actions Permalink

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

1
Comment actions Permalink

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.

4
Comment actions Permalink

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.

 

 

1
Comment actions Permalink

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.

-1
Comment actions Permalink

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.

0
Comment actions Permalink

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. 

 

2
Comment actions Permalink

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.

1
Comment actions Permalink

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

2
Comment actions Permalink

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.

0
Comment actions Permalink

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.

-1
Comment actions Permalink

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. 

1
Comment actions Permalink

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.

-1
Comment actions Permalink

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?

3
Comment actions Permalink

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
2
Comment actions Permalink

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
1
Comment actions Permalink

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

0
Comment actions Permalink

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. 

0
Comment actions Permalink

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.

2
Comment actions Permalink

The whole Resharper team really needs to make performance the number one priority. What's the point of a refactoring tool, if it's only usable in projects, that are so small there is no need for tool support?

Implement some default profiles, that deactivate different sets of features, by a simple mouse click.

The only way for me, to get Resharper to a nearly usable performance is, to deactivate the Windows Defender real time protection (no other AV software installed).

According to Microsoft, adding processes and folders to Windows Defender's ignore list will only exclude them from regular scans. The real time protection does not honor these exclusions. You have to turn off real time protection (which will turn itself on again after a while) or Windows Defender, to actually get a decent performance gain.

In addition to that, disabling Unit Testing in Resharper helped a lot in performance and in stability. Before that, VS was crashing multiple times an hour.

Also, there is currently considered a feature request on GitHub for a power saving mode in VS. Looks promising so far.

Edited by laucomm
0
Comment actions Permalink

This blog post is a sad joke to me. As many here and on other places I have near unusuable performance using Resharper C++. And reading this blog I want to smash my screen. Like others here my dev machine has far better specs than the minimal requirements (and before anyone ask: yes I read and applied all those fancy performance tips) and not too huge project with half a million LOC.

To me one thing is clear: The issue is not my PC, or VS. It's all Resharper. Yes, devenv is a 32bit process. Deal with it. Others manage it to, most notably VisualAssistX. Why is resharper such a memory hog? No system spec in the world is saving performance, if your active program is hitting the page file. An SSD doesn't help with that. Why does Resharper insist in scanning dozens of files to rename a *private* Member? Why does "Rename method"/"Change Signature" take so damn long anyway? VAX does both nearly instantaneous. Why is code completion so laggy you're faster just typing things? Unless of course typing itself starts to lag, which happens way too often.

Granted, Resharper has a few neat features that VAX lacks. But the performance difference is so enormous (especially on many common tasks), that picking between the two tools becoms a matter of weather you want to get work done or not.

0
Comment actions Permalink

I agree with Cewells the performance is so bad I am considering recommending that all our developers stop using it and find alternatives.

 

1
Comment actions Permalink

BTW, the fact das VS is a 32 bit process is not the issue for most people with performance problems. Visual Studio is compiled with the /LARGEADDRESSAWARE flag, that enables even a 32 bit process to consume up to 4 GB of memory on a 64 bit machine.

I enabled "Show managed memory usage in status bar" and never exceed 850 MB (with the devenv.exe process not consuming more than 1.5 GB total).

So the performance issues are a problem of the Resharper code base, not VS.

0
Comment actions Permalink

You seriously need to fix this soon.

 

0
Comment actions Permalink

@laucomm Interesting. Since I monitored devenv's memory usage in task manager. And during some of the stutters it's memory usage hovered at ~1800MB, while generating millions of page faults in a few minutes. Besides, the 32bit argument is actually also brought up by JetBrains in their performance tips article.

0
Comment actions Permalink

Microsoft announced Roslyn Analyzers over 5 years ago and released the first version at the end of 2015. https://github.com/dotnet/roslyn-analyzers/releases/tag/v1.1.0

Jetbrains immediately whined like weak sauce because they didn't want to rewrite their products based on the new Roslyn Analyzers.

We knew their failure to re-invest on their success was the beginning of the end, and now we've well arrived.

Other companies like with CodeRush embraced the future of Roslyn Analyzers and started working on it right away.

Jetbrains is quick to take our B2B steady money and slow to fix ANY mistakes, even "bugs" not related to performance; I've yet to see a solution that doesn't have false-positives from ReSharper. There are many better alternatives to JetBrains products: CodeRush, VirtualAssistX, new versions of VS, try anything.

Using JetBrains products on top of VisualStudio is like putting a pig on lipstick.

Don't be close-minded like JetBrains, embrace the future and embrace change.

Edited by Andrew Ackerman
1
Comment actions Permalink

It seems Resharper is just CPU miner.
After many years of using this tool I've removed it from VS. Terrible performance. I understand that main idea to switch users to Rider, but no respect if you do it this way.

1
Comment actions Permalink

I managed to convince my company that ReSharper is causing more trouble than it solves. We will slowly get rid of it now. Good day!

2
Comment actions Permalink

Same here, we slowly stopped using it. It is very unlikely we renew our licenses. Most of our devs are already using a plain VS with its default features.

2
Comment actions Permalink

I will, schedule a week in my calendar, where I will disable Resharper to test, how it impacts my development process and see, if I can find the right addons for the features that are still missing in plain VS.

2
Comment actions Permalink

I've been using VS2019 all day with no memory or performance issues at all ... because I removed R#.

We will not be renewing the license. Such a shame as it was a great product.

1

Please sign in to leave a comment.

Have more questions?

Submit a request