What is being done to improve the performance of R#6?

I have a serious problem with R# performance. Most of the time I am not willing to sacrifice speed of VS2010 for the features in R# although I do like the features. How is the performance issue going to be addressed? That was one of the BIGGEST problems my team had with R#5. It is significantly slower that VS2010 without R# - maybe on the order of 5-10 times slower depending on the operation. Just some things we noticed is that builds take longer on the order of 5 times longer and general code editing is very slow on the order of 7-8 times according to our timings. I am looking to see a significant improvement in R#6 with regard to this but so far during my tests am seeing R#6 is MUCH MUCH slower than R#5 which makes me VERY hesitant to buy it.

7 comments

I am not trying to criticize, I would just like to see what kind of performance tests are runin VB.NET because I am seeing HUGE performance problems virtually everywhere from editing files to generating properties, etc - my VS2010 slows down to a crawl. Any files where LOC > 30,000 are just impossible to edit when R# is enabled so I have to disable it which is a big hassle for me. Just want to see if we can maybe suggest some tests for you to run to improve these performance problems. I am seeing HUGE and unacceptable slowdowns in VB.NET solutions. Just want to find out what tests you already run to look at performance problems.

0

Hello,

We're eliminating any performance problems that we're able to identify and
fix. Do I understand correctly that the problem is with large files (>30k
LOC) only or you experience the same problem with smaller files (< 3k LOC)
as well? ReSharper's solution itself has lots of VB.NET files, so the performance
is being tested by our developers on the latest builds each day. Thank you!

Andrey Serebryansky
Senior Support Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I am not trying to criticize, I would just like to see what kind of
performance tests are runin VB.NET because I am seeing HUGE
performance problems virtually everywhere from editing files to
generating properties, etc - my VS2010 slows down to a crawl. Any
files where LOC > 30,000 are just impossible to edit when R# is
enabled so I have to disable it which is a big hassle for me. Just
want to see if we can maybe suggest some tests for you to run to
improve these performance problems. I am seeing HUGE and unacceptable
slowdowns in VB.NET solutions.

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



0

I am having MAJOR problems with files that are > 30K LOC - I can't use R# at all with those VB.NET files.

For VB.NET files < 3K LOC the problem is also bad when editing but R# is kind-of-usable if you have patience. Not a lot of developers are that patient.

If you compare just using VS2010 without R# to using VS2010 with R# you will see a HUGE difference - a HUGE boost of performance when R# is disabled or better yet, uninstalled! Try not using R# for a day or two in VB.NET projects and then turn it on. Just simple tasks like creating a new method/property take 5 or 6 times longer when R# is enabled

0

Hello,

There's a known problem that makes ReSharper slow on very large files (>30k
LOC), but I'm afraid we won't be able to fix it soon because it involves
some big changes. As to smaller files, there might be a problem we're not
aware of, so could you please capture a performance snapshot on a smaller
file ( <3k LOC) using dotTrace Performance 4.5 (which is available at http://tinyurl.com/63p6rsd
and which has prolonged evaluation) and upload it to ftp://ftp.intellij.net/.uploads/?
Thank you!

Andrey Serebryansky
Senior Support Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I am having MAJOR problems with files that are > 30K LOC - I can't use
R# at all with those VB.NET files.

For VB.NET files < 3K LOC the problem is also bad when editing. If you
compare to just using VS2010 without R# you will see a huge
difference! Try not using R# for a day or two and then turn it on.
Just simple tasks like creating a new method/property take 5 or 6
times longer.

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



0

That's too bad about large files. I think the MAJOR performance problems start much earlier than you specified. I am

seeing them starting maybe around 10K LOC, not 30K LOC. Most of our files are > 10K LOC. It's VB.NET after all that was converted that originally was MS Access.

It would be great if this problem could be fixed for R#6 because as it is right now we can't use R# on most files we have. Things become incredibly slow almost to the point of VS2010 become unresponsive.

0

i also have problems with large VB files. Yesterday i got an  OutOfMemoryException while editing a file > 10.000 LOC. My VB  solution was migrated from VB6. What i'm doing is subsequently refactor  the code while maintaining the solution (that's the main reason for me  to use R# ;)). Meanwhile i have just a handful of large files which are problematic with R#.

I  notice performance decrease on files larger than 5.000 LOC and Form  classes with a large .designer.vb file. But for me it's not so bad that i  have to disable R#. I've seen that the hardware has an influence on  R#'s performance. I had a big boost as i changed from an old single  core hyperthreading CPU to a dual core.

On my working place i have to work with Visual  Studio 2008 (Desktop, 2,7GHZ dual core, 3GB RAM, Windows XP SP3), but the performance while working on my solution is nearly  the same in Visual Studio 2010 (Laptop, 2,7GHZ dual core, 4GB RAM, Windows 7 64 Bit SP1).

Performance of R# with VB is an old theme. There was only one time in  the 4.x EAP builds where R# was as fast as with C#. I remember this  because i was in contact with Olga Lobacheva at this time and made some  performance snapshots which helped to solve the problems. After this the  VB performance decreased again, but never so much that it become unusable (except some EAP builds :D).

My tip for you: try to refactor your code and make the files smaller. My  experience was, that specially large Modules and large method bodies  have an impact on the editing performance. I had a module with around 25.000 LOC  which made the editor nearly unusable also with other files. In this  module all printing functionality was centralized. After refactoring the  printing functionality to one class per report, the editor was significantly faster.

Regards
Klaus

0

I, too, am seeing agonizing performance problems in VB.Net.  I'm a C# developer that is most definitely hooked on Resharper.  I recently inherited a moderately sized VB.Net application and have since had to uninstall JetBrains Resharper R#6 from my VS 2008 installation so VS would be responsive enough to use, although obviously at the cost of developer productivity. In reading this thread, I understand that it may take some time for you guys to work out the issues. I respect the challenges that you are facing with VB.Net, however, maybe there are some things to mitigate the pain that you could share?

Is it possible for you to give some idea of what options may be causing the performance issues?  If I could turn off a feature or two, but keep the bulk of ReSharper, I'd be in much better shape.  I pecked around a bit, but didn't find a silver bullet anywhere . . .

Thank you!

0

Please sign in to leave a comment.