ReSharper performance

Yes, this will be another post about poor performance of R#.

I've been using R# since version 4. At that time, our work solution comprised of slightly above 100 projects and it was not possible to use R# with the whole solution. But when I unloaded the projects that I did not need, I cut the number to around 30 and R# was more or less usable (but it keeps underlining the code referencing types from the unloaded projects - why, when everything compiles fine? this problem continues up until now). I was enthusiastic about R#, recommended it to my colleagues and wrote a review to support what I regarded as good product.

Each new version of R# promised improved performance, but I never noticed a big difference.

As time went by, the solution grew even more, now it is about 150 projects. When I unload those projects that I don't need, I got about 50, but R# is not usable even with this limited solution. VS get unresponsive very often and after some time of work, OutOfMemory exception begin to pop up.

I am not using R#  any more, even though I love its features. I now regret the time I spent learning to use R# effectively and lost the habit of using the built-in capabilities of VS. They lack nice features of R#, but at least they don't make VS unresponsive each once in a while.

I uninstalled R# recently. I will look for alternatives (maybe Telerik product, as is suggested in this post http://devnet.jetbrains.net/thread/432674) or just wait until MS incorporates the most critical features into Visual Studio itself.

53 comments
Avatar
Andrey Serebryansky
Comment actions Permalink

Hello Mike
     This one comes from the File Structure window, so I'd suggest to check if working with this window closed helps to avoid OOM errors. Thank you!

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

0
Comment actions Permalink

32-bit legacy apps should run just fine on Win7 64bit.

Visual Studio itself is a 32-bit app.


"Charles Hooks"  wrote in message
news:20760308.28271326402475889.JavaMail.devnet@confluence.jetbrains.net...

Our company is also using 32bit OS.  Until we can upgrade all of hte legacey
apps to 64 bits, which is still a year away...

We are stuck with 32 bits and R# is not usable for me with 6.1.  I'm lucky
to get more than an hour of coding before an OOM crash occurs.

Without R# no crashes at all.  I had no problems before version 6 came out.


---
Original message URL: http://devnet.jetbrains.net/message/5448853#5448853

0
Comment actions Permalink

I really have to wonder what the collective cost to these organizations that supplied their developers on this thread with inadequeate hardware to complete their jobs properly. I would really assume the time loss due to improper resources of just the few developers (and their related teams) in this thread would equate to hundreds of thousands, if not millions of dollars over a year.

0
Comment actions Permalink

I don't see how your comment is relevant to the conversation, but for sake of argument...

Lots of companies have invested in software that only works on the x86 platform.  Many of these applications are expected to live for 5-15 years and possibly longer before replacement.

Now in the case of our company we are slowly porting various applications when they need changes...   Porting old Borland C++ win32 apps to Visual Studio.  We do build new apps for x64, but we still have to support the old.  Unfortunately, these old borland apps do not run on an x64 OS, even when we try x86 mode and we have 100's of these old apps.  So when we can we upgrade them, but until they're al upgrade we're stuck with x86 os.

0
Comment actions Permalink

Unfortunately that is not true for most of our Borland apps.  They have custom interfaces with a variety of hardware to pirnters, inserters, scanners, bar code readers, etc.  We have tried to run them on x64 a couple of times and it has failed.

0
Comment actions Permalink

Excuses. Even with your organization being one of the rare needs for truly using x86, that still doesn't negate the need proper resources. With proper machines you could develop in Visual Studio in x64 and for legacy 32bit work develop inside virtual machine(s). This way multiple gigabytes of ram could be allocated even with XP's 3.2gb usable limit, with VMs you could easily run 3 VMs concurrently (even with only 12gb of ram) and dedicated 3.2gb to specific projects if they're gigantic.

My analogy that i used above is perfectly fitting. R# is a gigantic database that sits over your code. The larger the codebase, the larger the database. Blaming R# for using the memory it needs (which I would argue it uses substantially less than it should) and your system not being able to provide it, is a silly argument.

Would you seriously blame Redis, MongoDB or Sql Server that were in the exact same scenario that they're not provided enough resources to run the database it's told to run? Of course not.

Hardware is ridiciously cheap, wasted time is ridciously expensive as not only does it have direct costs on reduction on employee production it has opportunity cost attached to it making the time wasted a double cost. Lower productivity, and lower opportunity to do other things.

Regardless even if your organization refuses to replace your legacy hardware with modern hardware you still have numerous options, not using R# solution wide analysis, if that still doesn't push down the needs enough, at that point your projects need seperated. There's no need for solutions to have hundreds of projects. 50 projects is about the maxiumum that is ever reasonable in a solution. Past that you should be more concerned with sharing code in sane fashions aka nuget packages. There's no need for every project under the sun to be in 1 solution when you can easily share the dependencies it needs with nuget. Having solutions that collasal clearly shows no seperation of concerns, and falls into the god object anti-pattern. Code patterns and good design don't just apply to code, they can also apply to code structure and methodology.

You can also use nuget from the command line for sharing projects that aren't .NET projects. It wouldn't have as beautiful of an experience as it does inside Visual Studio, but it could definitely be used to share any code or dependencies in existense. Just the way you could use gems or npn to share anything.

0
Comment actions Permalink

R# 5 worked fine, R# 6 crashed and died horribly.  Do a search of the forms and you'll see my request to back down to version 5, which went unanswered.

Regardless of your opinion on what a viable development shop should be or have.  There was no indication from JetBrians that upgrading to V6 would require such a drastic change in the development environment.

At this point, the lack of support and the virtol from posters like yourself is just pushing shops similar to the one I work in to other vendors.  You buy a product to solve problems, not create them and R#6 is creating more problems than it solves and changing our entire development environment is not an option.

0
Comment actions Permalink

Always nice to see an open mind.

Some people are saying that R# is slow/unusable in some scenarios. JetBrains asks for help, more information, profiler snapshots etc. - maybe because they agree that it should not be slow in these scenarios? But you know better - you tell us that we should get bigger machines.
There are people in the world, who try to optimise their algorithms, find new data structures, because they know that buying better hardware is not a solution.
Please have in mind that R# is an add-on for Visual Studio, replacing it with its own functionality in some features. It does a lot of things, but still, I don't see a reason why it should not be happy with HW that runs Visual Studio without any difficulty. Your comparison is exorbiant. How about when you were running Firefox just fine on 32bit machine, install a plugin that manages your bookmarks more effectively, observe performance issues - and you are told that you should buy 64bit HW and stop complaining writing from your crappy PC.

When your customers complain that your product is slow, do you also tell them to buy better HW? Good luck with that. Maybe some of them will switch to your competitors, which is what I, and maybe others in this thread, did.

0
Comment actions Permalink

As for the comments on projects, all of our solutions have less than 10 projects with most just having 5 or 6.

The most common solution project listng is similar to the following listing:
Unit test Lib
Common Lib
Code Lib
Execution Harness (service, command line, etc...)
WiX installer
Fit Lib

0
Comment actions Permalink

If that's the size of your solutions, unless there's like 8 billion code files in them, I would say yes R# should work on a 32bit machine. But this could directly relate to the # of visual studios open, the number of other apps running (are virus scanners messing with index files for R# etc)

0
Comment actions Permalink

That's a compeltely inaccurate comparison. Visual Studio itself will occupy a large amount of memory. When you factor in you're probably running Web browser(s) or the apps your developing, Office products, Communication products, and any other software that is active on your system when you look at Windows XP you only have 3.2gb of available memory ever (assuming you have atleast that much physically).

Also there are many issues on Windows XP related to heap fragementation that even if your machine has enough bytes to store everything in memory that you can still get OOM exceptions because there isn't contigious blocks of memory large enough.

Your comparison with Firefox would only be accurate if the addon hoists a large a database on top of firefox.

In response to your statement "if your customers complain a product is slow", if my product was a database, I would have no issues informing them better hardware = better experience. Of course I also would likely make older versions available that are less robust for legacy hardware.

0
Comment actions Permalink

Only 1 visual studio is running.  However in our environment we have to use encrypted machines, so the whole drive is encrypted.  Plus the other 'special' hardware and the machines are dogs.

While I can run two instances of VS without R#, without problems a 3rd instance causes the same problems I get with 1 instance of VS with R# 6.0 or 6.1.  We are in process of getting solid state drives and some of my team members have them now, but that hasn't helped with the errors, though it has made everything so much faster that I am quite jealous of them. :(

0
Comment actions Permalink

Nice Debate , I missed it as I was sunbathing !!

While I do not wholly disagree with the resource loss argument from Chris , but after 40 years in a corpoarate world you learn that sometimes we have to live with what we are given and make the best. Debating 32 v 64 bit architecture with an accountant normally has little if any impact . In a dedicated software house the argument may wash  , I am not in that environment we are a FMCG comapany.

I do however take up the previous argument, if R# 6 was going to be so much more demanding that previously maybe warn us before we but it. Finding out when it crashes VS is not really the way to do it.

I do feel a bit agreived by Jet Brains " innocent until proved guilty "  approach they always want to see "proof" before they investigate. We all develop software , or we would be commenting here, and we all know how difficult it can be to root out some lurking performance issues, but Come Clean and admit they may be there maybe ....

I am working on 2 sorts of projects , big complex ones at work , small , hopefully well designed ones at home. The home ones are max 6 structured projects to a solution, and the one I am working on at the moment as my reference point has maybe 30 classes per project. I use this as a reference to see what changes , as this project doesn't. So the complaints based on Monolithic Solutions is not valid.

The real dilemma is that when you look for an alternative to R# , it isn't there . Visual Assist X is brilliant , but only covers 50% of R# . Just Code is good and improving but they seem to not see a need for Intellesence , CodeRush is Just Different....

So we get back to using R# and put up with the issues , but in our case why put up and shut up when we can debate as we are doing . Maybe Jet Brians will comment on this thread sometime , Andrey has commented but , with all due respect, without really joining the debate.

I am rapidly looking towards Visual Assist X and Code Rush Express to provide the best coverage without the memory issues.

Lets see what Jet Brains can come up with

Mike

0
Comment actions Permalink

MikeONeill wrote:

... CodeRush is Just Different....

Mike


Yeah, I'm glad someone agrees. I tried to switch to CodeRush but I just couldn't. It's definantly a different way of thinking. Too bad I just can't think that way...

Thanks,
Bobby Cannon

0
Comment actions Permalink

Hi Bobby

Bit rude advertising competitors BUT ...

Maybe try a demo of Visual Assist X if you haven't already , its a bit C++ Biased and has a few holes in VB  Refactoring but for C# its fine. The Tools like Outliner match R# equally .

its very similar to R# but covers a lot less , and I think is less memory demadning as a consequence. I have used the freebie Coderush Express along side with no issues just to supplemt the shortfalls in Refactoring.

Mike

0
Avatar
Andrey Serebryansky
Comment actions Permalink

Hello Mike and All
     I'm afraid this discussion has gone off topic, because the main purpose of this community is asking questions about Resharper and reporting bugs.

     In order to summarize the problems mentioned here I kindly ask everyone involved in this discussion to install the latest build of ReSharper 6.1.1 from http://confluence.jetbrains.net/display/ReSharper/ReSharper+6.1.1+Nightly+Builds and reply to this message with description of the problems that you've encountered with this build. That will give us some common ground to continue working with.
     Thank you!

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

0
Comment actions Permalink

Hi Andrey

I am sorry if dicussions here hit a sore point , I have given up on R# , I am trying to find something that replaces your functionalty , take it as a complement that this is not easy

If I find a fellow sufferer then so be it

I have been a devoted R# user for years and find it very hard to give it up , but while I cannot use it without VS 2010 crashing what am I to do, I have often used the Love Hat comparison , I lobe the product but I simply cannot live with its foibles , Am I Alone ???

If you find my comments re Jet Brains painful then maybe you should take note of that  and do something about it.

I spent good money upgrading to V6 and I have had nothing but pain since , I had few peoblems with V5 , and even less with with your competitors products

I will stop contributing to this thread if that please you , after all censorship keeps the masses in the dark

GOODBYE , and goodbye to Jet Brains products if thats what you want

Mike

0
Comment actions Permalink

PPS

Can I have a refund of my upgrade costs ?????

0
Avatar
Andrey Serebryansky
Comment actions Permalink

Hello Mike
     Please take my apologies for the poor experience that you've had with ReSharper. I sincerely hope that in the future you'll find some time to install newer versions and they will work better for you. Sure, you can have a refund. Please send me an e-mail to andrew dot serebryansky at jetbrains dot com.

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

0
Comment actions Permalink

I have also an annoying problem with my studio+resharper 6.1.1000.82. Sometimes it does not let me just edit my code. I must wait for a couple of seconds if i want to type a word. I thought first it happens only in some very big cs files ~4000 with a lot of inspection issues. But today i have the same issue in a relative small ~200 lines file with no bulbs. I have used dotTrace from EAP to generate a snapshot. During editing about 5 minutes and make some refactorings, dotTrace has generated a 5,5 Gig! snapshot. I have packed it to 1.8 Gig "bigCs.zip" and uploaded it per ftp to ftp://ftp.intellij.net/.uploads/ like described in http://confluence.jetbrains.net/display/ReSharper/ReSharper+Profiling+Instructions.
This is a .net 4.0 winforms solution with 20 cs projects

0
Avatar
Andrey Serebryansky
Comment actions Permalink

Hello Andreas
     Thank you for feedback! At the moment I cannot find anything suspicious in the snapshot. Also, it shows that there are some other third-party extensions present and doing their work. First of all, could you please check if suspending ReSharper (under Tools | Options | ReSharper | General) helps to aviod these performance problems?

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

0
Comment actions Permalink

Yes, suspending R# helps definitely. But i will experiment with uninstalling of some VS extensions anyway.

0
Comment actions Permalink

well, seems that the villain is the other VS addin - GitScc! My suspection about resharper was probably my imagination... nevermind :)

0

Please sign in to leave a comment.