R#'s sluggishness should not slow down the text editor. A comparison with a competitor

I have been reading many posts and complaints about Resharper's slowness in large/very large projects for years. I am lucky enough that my Visual Studio solutions are not too large for Resharper to affect its performance.. until today when I had to open a solution with 55 projects. (Note that most of the projects in the solution are independent web service projects without direct references. Just web references. I am saying this because maybe R# doesn't have to do full code analysis. I don't know how R# works)

I can see and feel now the complaints. Resharper was so slow, I couldn't bear it anymore. I hate to be working in an editor which can't keep up with my keystrokes. I had to wait for seconds for even the cursor to move. Visual Studio went into several 'Not Responding' modes I thought it crashed.

I decided to do a test. I suspended Resharper and downloaded and installed the latest Telerik JustCode.
JustCode took a while to inspect and analyze the code. I am OK if it does a one time long analysis and be zippy from that point. And that's what seems to be the case. I was able to type and do stuff pretty easy in VS without VS bogging down. So now.. if a competing product can handle the same big solution, I am going to blame Resharper and not the size of my solution for Resharper's bad performance.

I was trying to see what JustCode was doing and guessing how it works. I think what it does is that it suspends its analysis and gives the user priority while the user is typing. Or it does it in the background in a separate process. (There's an option to enable the 64bit process). It is VERY important for me to be able to type code.. and as fast as I can. I am OK with the tool analyzing my code 5 seconds later, 10 seconds later or even 30 seconds later. It seems Resharper is too eager to analyze the code while I type and if I type fast or paste some code, Resharper seems to quickly  analyze the code and the IDE becomes very sluggish, when the solution is very large.

My other guess is that JustCode works as a separate process outside of Visual Studio which gives it an advantage doing work without competing with Visual Studio. I see the process in the Task Manager.  Resharper seems to work inside VS only? I don't know but because of this, there's a plateau for Resharper for their performance optimization and there's only so much they can squeeze for performance improvements?

Without knowing the internals of both products, I am just guessing that JustCode is taking the correct approach in its analysis method. I love Resharper's features and JustCode's performance. I wish Resharper has both. (and I haven't tried CodeRush)

However if JustCode developers are able to add features without affecting its performance too much, Resharper developers will need to worry. Worry that R# users might switch over.

It does me no good if I use a tool which is full of nice featues but its performance is bad. Over the years I have seen promises and notices about enhancements in performance but yet many developers are still not happy with the performance.

I have been using Resharper for years. I love the product and paid a few times for upgrades.

I am just glad that I won't be working on this 55 project solution for too long. Otherwise working on it would be a miserable experience.



Feel free to correct anything wrong I said.

15 comments
Comment actions Permalink

every time i read posts that 50 or more projects in a solution lead to performance problems i get headache. For me it's a bad smell
to work on such large solutions. Does it really make sin to keep all the source code in one solution? From an architecture view i
would analyze the solution an break it up into smaller components, place them in separate solutions and then use dll references.

I never worked on such large solutions with Visual Studio 2010 but i remember a project i'm working on a few years ago with Visual
Studio 2008 where we had massive compile time problems on such a large solution (and even we don't us R#). After rearranging the
code from one large to 7 small solutions our developers could compile their code in under a minute instead of half an hour or so
before. The complete build on TFS lasts 20 minutes instead of 6 hours.

Regards
Klaus

0
Comment actions Permalink

every time i read posts that 50 or more projects in a solution lead to performance problems i get headache. For me it's a bad smell
to work on such large solutions. Does it really make sin to keep all the source code in one solution? From an architecture view i
would analyze the solution an break it up into smaller components, place them in separate solutions and then use dll references.

I never worked on such large solutions with Visual Studio 2010 but i remember a project i'm working on a few years ago with Visual
Studio 2008 where we had massive compile time problems on such a large solution (and even we don't us R#). After rearranging the
code from one large to 7 small solutions our developers could compile their code in under a minute instead of half an hour or so
before. The complete build on TFS lasts 20 minutes instead of 6 hours.

Regards
Klaus

0
Comment actions Permalink

Number of projects in itself is not indicative of anything. I could have a 50 project solution which is a lot smaller than a 10 project solution. It's all relative. My solution compiles in less than 5 minutes. Not close to an hour, let alone 6 hours.

Like I said, if another product can handle my solution, then the problem does not lie with the solution size.

The projects are actually developed in their own solutions. We have a master solution which includes all of them.

0
Comment actions Permalink

Performance is poor in larger solution for sure. It made me stop using ReSharper completely (http://devnet.jetbrains.net/message/5446740#5446740).

0
Comment actions Permalink

Hello
     Which version of ReSharper are you using at the moment? Thank you!

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

0
Comment actions Permalink

I was using the EAP of two days ago so probably build 34.

0
Comment actions Permalink

BTW, I am not trying to glorify other products. I tried CodeRush today and it was just bad. It didn't report some simple errors which VS reported as errors and I didn't like many of the UI stuff. I ended up uninstalling after a few hours it as it has serious issues. I am still a very big R# fan and try every single EAP build because I seriously want it to improve.

0
Comment actions Permalink

Hello
     Thank you for feedback! I'm glad that you still like ReSharper :) However, it would be great if you could find some time to provide more information on the performance problems that you've experienced with that large solution, because we'd really like to make ReSharper faster in all scenarios. In particular, we'd like to know following things:

1. Your hardware configuration
2. What kind of projects are there in that solution (web projects, silverlight/wpf or something else)?
3. How big were the files you were editing (in terms of LOC)?
4. Which actions were slow and how slow they were (seconds, minutes)?

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

0
Comment actions Permalink

Just as a side note, it seems like we're going backward in respects to performance with the newer builds.  It seems like performance had started to improve quite a bit, but in the last couple builds (35 and 36) it seems like it's getting worse again.  This is mostly anecdotal on my part, but I also notice that the manage memory indicator seems to climb up pretty fast; and then telling it to collect garbage brings it back down pretty significantly (like from 400MB down to 300MB).  But typing in the text editors is definitely back to being pretty sluggish.

0
Comment actions Permalink

I am using I7 CPU quad core 1.8Ghz, 8G ram and Windows 7 64bit.
Most of the projects are asmx web service projects and the rest are class projects.
The file I am working on has @1500 LOC.

The delay happens when I am typing or editing fast enough to make Resharper be in "Analysis in porgress" for a few seconds. I mean I would be hitting the Backspace key and nothing happens and I have to wait like at least 3 seconds. It seems to me that it should be in "Analysis will start Shortly" mode more often as I type. Sometimes analysis gets paused indefintely until I hit a key, which is not a bad thing.

I installed 6.1 release version today and I feel it's faster. I will see how it goes with this big solution. I might have to start using ctrl-shift-alt-8 and bear it when unbearable sluggishness occurs in a slow file.

Thanks.

0
Comment actions Permalink

Luedi,

place them in separate solutions and then use dll references.


Which makes the 'R' in 'R#' completely useless.

--
/\/\arkus.

0
Comment actions Permalink

On 02.01.2012 11:18, Markus Springweiler wrote:

Luedi,

>
>> place them in separate solutions and then use dll references.
>

Which makes the 'R' in 'R#' completely useless.

>
maybe... I really don't want to start an architectural discussion here, but splitting a solution in so many projects has a bad smell
for me. Even the largest project i worked on (with around 2.500.000 lines of code, by the way, the reason i started to use R# :))
was split into not more than 15 projects. Normally i split my solution into projects by technical or/and functional boundaries.
Technical boundaries are the classic layers of an application (e.g Data Access, Business Logic, UI). Functional boundaries are a bit
more complicated because they depends on the requirements. If i use functional boundaries i prefer to define them very coarse
grained (eg. project Contracts contains the code for every business case related to contracts). Reusable code is placed in
components which are used as dll references. For refactoring i can always setup a separate solution where i bind all code as project
references together.

If you have an example where it is essentially needed to have more than 25 to 30 projects in a solution i may change my mind.

Regards
Klaus

0
Comment actions Permalink

Yup, same problem: Really slow when editing. I also believe this didn't happen in 6.1, it just started happening in 6.1.1.

x64 machine Quad Core with 8GB of RAM working on VB.NET solution which contains 4 projects.

0
Comment actions Permalink

Hello
     Thank you for feedback! Could you please provide some more details (such as a demo solution, a performance snapshot or some repro steps), so that we could investigate this problem on our side?

Andrey Serebryansky

Senior Support Engineer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"

0
Comment actions Permalink

Andrey,  I recently uploaded a snapshot demonstrating this for http://youtrack.jetbrains.net/issue/RSRP-274497

0

Please sign in to leave a comment.