Performance Slowdown in R#

I am fairly convinced that the performance slowdown in R# is MOSTLY due to the errors in the file. I have noticed a dramatic descrease in performnce for files which R# thinks there are errors (i.e. a lot of red or orange tick marks in the right hand column). If the file doesn't compile R# experiences a MAJOR performance decrease but once the error is corrected R# performance seems a lot better. I have seen files where total LOC > 10,000 and R# is fine because the file has a "GREEN" square at the top indicating there are no problems with it. I have also seen files where total LOC < 2,000 but that have a lot of tick marks on the right hand side. Even though the LOC is low, those files are impossible to edit if R# is turned on. I think this is where the big performance problems are:

(1) where there are a lot of tick marks

(2) When the error circle is blinking the performance degrades

(3) if there are any compile errors that are currently in the file - why is the file even analyzed if this is the case?

(4) when R# tries to fix indentation/parenthesis in files where there are compile problems - why is it trying to do that?

(5)  when you have a lot of files open in VS -- why is R# trying to reparse other files? it should only reparse the file I am currently working on. If I only have 1 file open at a time in R# then performance is at its best.

5 comments

I agree that performance is a perennial problem for R#, but they can't stop trying to analyse a file just because it contains an error, because otherwise every other file which references items in the first file will now have errors on all its references.  If they then stopped analysing those files, pretty quickly all analysis would stop across the whole project, possibly because of a single minor error.

But I have thought in the past that there might be a maximum number of errors in a file at which they would just give up and say it's hopeless to continue.   It is annoying when a vast cascade of errors and the associated slow-down is caused by one extra closed brace, and yet you can barely get the cursor to the right point to fix it because the editor is stuttering so badly.

0

i also agree with you and i see other problems specially when editing VB files:

  • Intellisense popup frequently needs 10 to 30 seconds to display and freezes the editor meanwhile
  • Processor activity is nearly always at 100% caused by devenv.exe. Even if i just edit a comment (not XML comment) Processor activity increase (This is not the case when i disable R#).
  • If you work mainly with the keyboard like me it's a pain to edit because of frequently delays. Sometimes i type a whole line of code and it is not displayed before i press Enter (maybe i type too fast ;)). Navigating through the source with the cursors keys is nearly impossible because of the delays, specially when you hold down the cursor key for a longer time to scroll to some point. I don't know why the processor activity must risee to 100% just when i scroll through the code with the curosr.


My guess for the bad VB performance is that the VB editor itself permanently analyzes the file to show Compile errors in the error window. This may block the R# analysis thread. My wish is that the Jetbrains guys develop an own VB editor addin for Visual studio because for me the overall user experience of the built-in VB editor is horrible in opposite to C#.

Regards
Klaus


Addendum: After disabling R# intellisense, editing rocks :)

changed by Klaus Luedenscheidt

0

Hello Denis,

That's true, when there are too many errors/problems in a file it takes some
time to draw all of them on the error stripe and this slows things down a
bit. However, it would be really great if you could give us some performance
snapshots, so that we could identify the exact problem. Also, could you please
clarify points (3) and (4)? Do I understand correctly that if there's even
a single compilation error in a file, ReSharper should immediately stop highlighting
it and stop providing typing assistance? Could you please also describe (5)
in more detail, in what case ReSharper does re-parse (or re-analyze) the
other files for you? Thank you!

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

I am fairly convinced that the performance slowdown in R# is MOSTLY
due to the errors in the file. I have noticed a dramatic descrease in
performnce for files which R# thinks there are errors (i.e. a lot of
red or orange tick marks in the right hand column). If the file
doesn't compile R# experiences a MAJOR performance decrease but once
the error is corrected R# performance seems a lot better. I have seen
files where total LOC > 10,000 and R# is fine because the file has a
"GREEN" square at the top indicating there are no problems with it. I
have also seen files where total LOC < 2,000 but that have a lot of
tick marks on the right hand side. Even though the LOC is low, those
files are impossible to edit if R# is turned on. I think this is where
the big performance problems are:

(1) where there are a lot of tick marks

(2) When the error circle is blinking the performance degrades

(3) if there are any compile errors that are currently in the file -
why is the file even analyzed if this is the case?

(4) when R# tries to fix indentation/parenthesis in files where there
are compile problems - why is it trying to do that?

(5)  when you have a lot of files open in VS -- why is R# trying to
reparse other files? it should only reparse the file I am currently
working on. If I only have 1 file open at a time in R# then
performance is at its best.

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



0

for (3) and (4) I guess they might be related, this is the example where VS is reporting there are compile errors. I was thinking that if there is a compile error like mismatched "foreach/next" or "if/end if" or "someobject." (without the method or property call following the ".") or other mismatches like this then the R# analysis could be stopped for this file until the problem is fixed because editing becomes impossible - R# tries to re-analyze the file but since the closing block is missing the analysis goes completely crazy because nothing makes sense and R# starts reporting a zillion errors and therefore performance becomes ridiculously slow and the file becomes impossible to edit.

Also to add, I noticed that R# tries to analyze all open files, i.e. if a tab is open for a particular file R# is analyzing that file. This can be easily reproduced if you open 30 files in different tabs in VS2010 and try to edit some file and then compare this to closing all the tabs except for the tab which holds the file you are editing. There is a big performance difference. In reality, I think there shouldn't be. In VS I can only edit 1 file at a time. That is the file that should be analyzed. Why do you need to re-analyze the other tabs that are open? (they're not changing)

0

I think I can safely say that when ReSharper finds errors in the current
file, it can take an eternity (or seemingly an eternity) as ReSharper seems
to crawl every file it thinks is related searching for issues and/or crawl
every file and reference it can find searching for an appropriate namespace
to import. We ran into this issue a while back when the public interface of
one our references changed during an update and I finally had to suspend
ReSharper so I could go through all the files fixing the references. I may
be wrong, but it seemed as if ReSharper started the crawl from scratch after
every fix. I f I duplicate this issue again, I'll send a performance
snapshot.

Another annoying issue I ran into with ReSharper 6 the other day is that it
found an "error" in  or and popped up a window asking me to import some
namespace. The import isn't necessary because the images are referenced from
the theme path using the theme defined at run-time. I finally suspended
ReSharper because that popup was acting like the annoying blinkenlights and
wouldn't go away.

"Andrew Serebryansky"  wrote in message
news:c8a898ddeb838cdbedb3e59f8e0@news.intellij.net...

Hello Denis,

That's true, when there are too many errors/problems in a file it takes some
time to draw all of them on the error stripe and this slows things down a
bit. However, it would be really great if you could give us some performance
snapshots, so that we could identify the exact problem. Also, could you
please
clarify points (3) and (4)? Do I understand correctly that if there's even
a single compilation error in a file, ReSharper should immediately stop
highlighting
it and stop providing typing assistance? Could you please also describe (5)
in more detail, in what case ReSharper does re-parse (or re-analyze) the
other files for you? Thank you!

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

I am fairly convinced that the performance slowdown in R# is MOSTLY
due to the errors in the file. I have noticed a dramatic descrease in
performnce for files which R# thinks there are errors (i.e. a lot of
red or orange tick marks in the right hand column). If the file
doesn't compile R# experiences a MAJOR performance decrease but once
the error is corrected R# performance seems a lot better. I have seen
files where total LOC > 10,000 and R# is fine because the file has a
"GREEN" square at the top indicating there are no problems with it. I
have also seen files where total LOC < 2,000 but that have a lot of
tick marks on the right hand side. Even though the LOC is low, those
files are impossible to edit if R# is turned on. I think this is where
the big performance problems are:

>

(1) where there are a lot of tick marks

>

(2) When the error circle is blinking the performance degrades

>

(3) if there are any compile errors that are currently in the file -
why is the file even analyzed if this is the case?

>

(4) when R# tries to fix indentation/parenthesis in files where there
are compile problems - why is it trying to do that?

>

(5)  when you have a lot of files open in VS -- why is R# trying to
reparse other files? it should only reparse the file I am currently
working on. If I only have 1 file open at a time in R# then
performance is at its best.

>

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


0

Please sign in to leave a comment.