I like ReSharper, but it is a total memory hog. It can quickly swell up and consume a half-gig of RAM without too much effort and bog down the IDE. Does anybody know of any way to configure it to be not as slow?
+5
A:
Turn off the on-the-fly compilation (which, unfortunately, is one of its best features)
cynicalman
2008-09-17 14:47:53
Thanks - as you say, this is somewhat annoying given how important the on-the-fly is. Their 4.1 release seems even flakier. I would hope that a company all about clean code would be able to clean things up to run faster.
Todd Williamson
2008-10-02 01:51:31
I found 4.1 to be even slower (particularly on solution load) than 4.0. Have since moved back to 4.0, primarily for that reason.
Richard Ev
2008-11-27 12:32:53
Where do you turn this off? I looked all over the options menu...
Mike
2010-10-01 22:49:51
A:
In previous versions I had the same problem, when 4.0 came out these problems have seemed to have gone away. Now with 4.1 i do not feel the huge slow down i used to have. My IDE does not freeze up anymore.
have you tried upgrading ?
Alexandre Brisebois
2008-09-24 16:31:55
We upgraded and got even worse results. We're using Visual Studio 2008. We had to do a complete uninstall to go back to 4.0.
Todd Williamson
2008-09-24 19:53:50
+4
A:
What bothers me more is the amount by which ReSharper slows down Visual Studio startup. Once it's up and running, I usually do not notice any major slow downs.
petr k.
2008-09-24 16:33:43
VS is very slow in giving us its project model, especially file properties, like BuildAction. Of course, we need to know if file is just text or it compiles :)
Ilya Ryzhenkov
2008-10-23 13:46:01
Aye this is the precise issue I suffer with VS2005 + Resharper. I just want it to boot quicker.
Quibblesome
2009-01-09 10:15:59
+5
A:
The next release 4.5 is going to based around performance and memory footprint.
see Ilya Ryzhenkov's blog
Resharper 4.5 has been released From my experience it is less of a memory hog, but i still can run out of memory.
tdyen
2008-10-13 06:42:03
+1
A:
Regarding memory hogging - I've found that my VS2008 memory footprint grows every time I close one solution and open another. This is true even if I close a solution and re-open that same solution.
Richard Ev
2008-11-27 12:34:28
@richard do you close the IDE or just the solution. I'd recommend you close the IDE when changing solutions. This stems from noticing in practice rather than any theory.
dove
2008-11-29 10:58:44
Normally I close the IDE, which is kind of annoying to have to do. Alternatively I turn off ReSharper.
Richard Ev
2008-12-01 10:22:09
+3
A:
Not sure how big your solutions are, but I stopped using 4.5 for the same reasons I stopped using all previous versions, memory usage.
Code analysis and unit test support was the main reason I bought it, turning it off means the rationale for using it is gone.
Workstation has 4GB of memory, and I can easily kill it with ReSharper when running our end-to-end stack in debuggers.
Leon Breedt
2009-04-12 23:07:03
A:
Try the 4.5 beta. 4.1 was killing my 2GB dev machine, but it's back to running incredibly smoothly with the beta. Others have had the opposite experience, though, so YMMV.
Chris Doggett
2009-04-12 23:12:13
+2
A:
You can look how much memory ReSharper use.
ReSharper -> General -> Show managed memory usege in status bar.
MicTech
2009-04-17 12:03:07
+1
A:
The new ReSharper 4.5 works a lot better than the previous 4.x releases. I would recommend you try that one.
__grover
2009-04-17 12:06:18
A:
Yes, 4.5 works much better. My understanding is that 4.5 was to address the performance issues.
Chuck Conway
2009-06-11 02:27:39
+3
A:
I had an issue where it was taking upwards of 10 minutes to load a solution of 100+ projects. Once loaded VS performance would be ok, though it would oddly flutter back and forth between ok and really bad.
The short answer: Eliminating Resharper warnings seems to improve overall VS/R# performance.
The biggest problem ultimately was that we had a number of files of binary data (encrypted stuff) being included as embedded resources, which happened to have .xml extensions. Resharper was trying really really hard to analyze those files. Eventually it'd get through but would generate 100K+ errors in the process. Changing the extension to one Resharper did not automatically analyze (.bin in this case) solved the problem.
We still have about 10 files which when they or a file they depend on is edited performance tanks for a while. These files are the partial parts of a single class definition where each file averages 3000 LOC. Yes, that's right, it's about a 30K line class. It also happens to be rather poor code for other reasons, many of which Resharper flags making the right hand gutter bar practically a solid orange line. Editing often causes Resharper to reanalyze the whole thing. While that analysis runs, performance is noticeably affected.
I've come to the conclusion that the less errors/warnings there are for R# to identify, the better it performs. My anecdotal evidence gathered while cleaning up/refactoring this project seems to support it.
A lot of folks complain of perf problems with Resharper. If you have even a few big ugly code files with lots of Resharper warnings, then a little time spent cleaning that code up might yield better performance overall. It has for us.
Josh Buedel
2009-08-18 04:10:59
+1
A:
If you are working on large source files, Resharper does get sluggish (I'm working on version 5.0 at the time of writing this).
You can view the memory usage of Resharper by clicking on Resharper options -> General -> Show memory use in status bar.
When I first did this, I noticed Resharper had clocked up hundreds of megabytes of memory usage! However, the next step worked for me in (temporarily) fixing the slugishness:
Right click the memory usage, and select "Collect garbage" - this seemed to fix the slugishness for me straight away.
Greg
2010-09-01 17:19:19