>> After build with Visual Studio resharper ususes 100% CPU for about 30 >> sec. and then it is back to normal >>
i had the same problem with Resharper 1.0. The project i work on has about 5000 classes spreded to 3 projects. Sometimes Intellisenese took about 20 to 30 seconds until the listbox appears and my whole system reacts very slow. After upgrading my main memory to 1GB the problems disappeared. I think the problem was that Resharper sonsumes up to 300 to 400 MB memory and so my system was swapping too much.
In my case yes. This is unfortunate since in this case I am unable to use resharper :(
2) What is the structure of your solution, in particular, what types of projects does your solution contain (i.e., C++, C#, VB)?
Solution contains 20+ projects, all C# ~2000 files total spreaded in dll's for about 10-20 in one dll
Problem grows as number of projects in the solution increases. It starts to appear for around 5-10 projects. It becomes unberable with 20 projects on a 512 Mb machine (I had to deinstall resharper). It'is manageable on a 1 Gig 3Ghz hyperthreaded machine but still takes ~10-20 sek after build to unfreeze VisualStudio. I will monitor memory usage. But in my case it is CPU.
Problem is in all EAP builds prior to 1.5. I haven't tried earlier versions.
could you also please describe what assemblies are referenced in your projects? In particular, do you reference projects' output assemblies?
It seems that the problem is caused by reloading referenced assemblies after build. That is, timestamps of referenced assemblies change after build and ReSharer believes that it should reload assemblies. Though this normally takes much less time than 10-20 secs, and I can hardly understand what happens exactly.
In my case yes. This is unfortunate since in this case I am unable to use resharper :(
>> 2) What is the structure of your solution, in >> particular, what types of projects >> does your solution contain (i.e., C++, C#, VB)?
Solution contains 20+ projects, all C# ~2000 files total spreaded in dll's for about 10-20 in one dll Problem grows as number of projects in the solution increases. It starts to appear for around 5-10 projects. It becomes unberable with 20 projects on a 512 Mb machine (I had to deinstall resharper). It'is manageable on a 1 Gig 3Ghz hyperthreaded machine but still takes ~10-20 sek after build to unfreeze VisualStudio. I will monitor memory usage. But in my case it is CPU.
Problem is in all EAP builds prior to 1.5. I haven't tried earlier versions.
could you also please describe what assemblies are referenced in your projects? In particular, do you reference projects' output assemblies?
Thats right. I have refferences to output assemblies instead of projects in solution.
It seems that the problem is caused by reloading referenced assemblies after build. That is, timestamps of referenced assemblies change after build and ReSharer believes that it should reload assemblies.
I guess that's what's happening. This reloading consumes all CPU and Visual studio freezes for 10-20 sec on a good machine and on less powerfull machine its unberable.
>> Hello, >> >> could you also please describe what assemblies are >> referenced in your projects? >> In particular, >> do you reference projects' output assemblies?
Thats right. I have refferences to output assemblies instead of projects in solution.
>> It seems that the problem is caused by reloading >> referenced assemblies after >> build. That is, timestamps >> of referenced assemblies change after build and >> ReSharer believes that it >> should reload assemblies.
I guess that's what's happening. This reloading consumes all CPU and Visual studio freezes for 10-20 sec on a good machine and on less powerfull machine its unberable.
Meantime, it seems that I forgot to clarify an important point: does that 10-20 sec delay happen after each build (that is, when you run Build Solution command) or after each actual rebuild (when output dlls do really change)?
That would be great. Maybe also a feature to temporary disable ReSharper at all if strange things happen. I don't know if it's possible with VS.
Meantime, it seems that I forgot to clarify an important point: does that 10-20 sec delay happen after each build (that is, when you run Build Solution command) or after each actual rebuild (when output dlls do really change)?
Actually it happens after rebuild, build and run commands. It seems to mee that VStudio fails to check dependencies in normal build case, when refferences are set to dlls instead of projects in solution. So VS decides to recompile everything (or most of the solution) in many cases, which naturally causes ReSharper to reload changed dlls. So it is reaaly a pain to wait 20+ secs after each even small change.
1) You can temporarily disable ReSharper using Tools->Add-In Manager. However, enabling it again will take a while on a large solution.
2) So it seems that you encounter delays in case if VS recompiles a large subset of your solution (and timestamps of output dlls => referenced dlls are changed accordingly). However, from my experience recompiling a large solution is such a time-consuming process that 10 sec delay after it does not almost add nothing. However, from your post I have to conclude that your solution recompiles fast and ReSharper's activity incurs a great overhead compared with VS build, is it really true?
That would be great. Maybe also a feature to temporary disable ReSharper at all if strange things happen. I don't know if it's possible with VS.
>> Meantime, it seems that I forgot to clarify an >> important >> point: does that 10-20 sec delay happen after each >> build >> (that is, when you run Build Solution command) or >> after each >> actual rebuild (when output dlls do really change)?
Actually it happens after rebuild, build and run commands. It seems to mee that VStudio fails to check dependencies in normal build case, when refferences are set to dlls instead of projects in solution. So VS decides to recompile everything (or most of the solution) in many cases, which naturally causes ReSharper to reload changed dlls. So it is reaaly a pain to wait 20+ secs after each even small change.
2) So it seems that you encounter delays in case if VS recompiles a large subset of your solution
Thats' right.
ReSharper's activity incurs a great overhead compared with VS build, is it really true?
Yes.
My specific is that I have a large number of relatively small dll's with relative high count of small classes. So compilation time is in the order of 30-60 secs, and then reloading dll's by resharper is order of 20-30 sec. To this may add that I am force to use currently only 2.8 Ghz Celeron with only 266 Mhz access to memory speed.
So it's really anoying also for the fact that reloading freezes VStudio. I guess that area may need optimization. Also this reloading could be done on separate low priority thread. So when I run my application after build or when I try to edit code again, resharper reloading impact will be minimal.
Of course, it's not good that reloading dlls freezes VS, but in a regular scenario, referenced assemblies are reloaded very fast, so that's not a big issue. Unfortunately, the architecture of ReSharper 1.5 does not allow to do reloading in a separate thread. But we'll definitely work on improving this in the 2.0 version.
>> 2) So it seems that you encounter delays in case if >> VS recompiles a large >> subset of your solution
Thats' right.
>> ReSharper's activity incurs a great overhead compared >> with VS build, is it >> really true?
Yes.
My specific is that I have a large number of relatively small dll's with relative high count of small classes. So compilation time is in the order of 30-60 secs, and then reloading dll's by resharper is order of 20-30 sec. To this may add that I am force to use currently only 2.8 Ghz Celeron with only 266 Mhz access to memory speed.
So it's really anoying also for the fact that reloading freezes VStudio. I guess that area may need optimization. Also this reloading could be done on separate low priority thread. So when I run my application after build or when I try to edit code again, resharper reloading impact will be minimal.
VS, but in a regular scenario, referenced assemblies are reloaded very fast, so that's not a big issue.
I think reloading of assemblies could be optimized. Its not normal that it takes about the same time as compilation itself.
I tried to use AddIn Manager to disable Resharper, but I found it annoying to wait while resharper loads at startup when I accidentaly press one of resharper shortcuts. Can I some how stop Resharper from starting automatically when it is disabled in AddIn manager?
We'll work on improving performance of assembly loading.
As for activating ReSharper when one of its shortcuts is pressed, unfortunately, there is no way to disable it - this is how the VS works. It loads & activates an add-in when one of its commands is invoked.
>> VS, but in a regular >> scenario, >> referenced assemblies are reloaded very fast, so >> that's not a big issue.
I think reloading of assemblies could be optimized. Its not normal that it takes about the same time as compilation itself.
I tried to use AddIn Manager to disable Resharper, but I found it annoying to wait while resharper loads at startup when I accidentaly press one of resharper shortcuts. Can I some how stop Resharper from starting automatically when it is disabled in AddIn manager?
Hi,
please provide more details:
1) Is the problem always reproducible?
2) What is the structure of your solution, in particular, what types of projects
does your solution contain (i.e., C++, C#, VB)?
Thanks in advance.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Dmitry Shaporenkov wrote:
>> After build with Visual Studio resharper ususes 100% CPU for about 30
>> sec. and then it is back to normal
>>
i had the same problem with Resharper 1.0. The project i work on has about 5000 classes spreded to 3 projects.
Sometimes Intellisenese took about 20 to 30 seconds until the listbox appears and my whole system reacts very slow.
After upgrading my main memory to 1GB the problems disappeared. I think the problem was that Resharper sonsumes up to
300 to 400 MB memory and so my system was swapping too much.
Regards
Klaus
In my case yes. This is unfortunate since in this case I am unable to use resharper :(
Solution contains 20+ projects, all C#
~2000 files total spreaded in dll's for about 10-20 in one dll
Problem grows as number of projects in the solution increases. It starts to appear for around 5-10 projects. It becomes unberable with 20 projects on a 512 Mb machine (I had to deinstall resharper). It'is manageable on a 1 Gig 3Ghz hyperthreaded machine but still takes ~10-20 sek after build to unfreeze VisualStudio. I will monitor memory usage. But in my case it is CPU.
Problem is in all EAP builds prior to 1.5. I haven't tried earlier versions.
Hello,
could you also please describe what assemblies are referenced in your projects?
In particular,
do you reference projects' output assemblies?
It seems that the problem is caused by reloading referenced assemblies after
build. That is, timestamps
of referenced assemblies change after build and ReSharer believes that it
should reload assemblies.
Though this normally takes much less time than 10-20 secs, and I can hardly
understand what happens
exactly.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> 1) Is the problem always reproducible?
>>
>> 2) What is the structure of your solution, in
>> particular, what types of projects
>> does your solution contain (i.e., C++, C#, VB)?
Thats right. I have refferences to output assemblies instead of projects in solution.
I guess that's what's happening. This reloading consumes all CPU and Visual studio freezes for 10-20 sec on a good machine and on less powerfull machine its unberable.
How many such references do you have?
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Hello,
>>
>> could you also please describe what assemblies are
>> referenced in your projects?
>> In particular,
>> do you reference projects' output assemblies?
>> It seems that the problem is caused by reloading
>> referenced assemblies after
>> build. That is, timestamps
>> of referenced assemblies change after build and
>> ReSharer believes that it
>> should reload assemblies.
it is a part of an enterprise scale application.
It uses ~5 such refferences in each of 20 projects.
Test application uses all 20 refferences
I would like to propose to have a chekcbox in optionas to disable refferenced DLLs reloading after build.
We'll consider that.
Meantime, it seems that I forgot to clarify an important
point: does that 10-20 sec delay happen after each build
(that is, when you run Build Solution command) or after each
actual rebuild (when output dlls do really change)?
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
That would be great. Maybe also a feature to temporary disable ReSharper at all if strange things happen. I don't know if it's possible with VS.
Actually it happens after rebuild, build and run commands. It seems to mee that VStudio fails to check dependencies in normal build case, when refferences are set to dlls instead of projects in solution. So VS decides to recompile everything (or most of the solution) in many cases, which naturally causes ReSharper to reload changed dlls. So it is reaaly a pain to wait 20+ secs after each even small change.
1) You can temporarily disable ReSharper using Tools->Add-In Manager. However,
enabling it again will
take a while on a large solution.
2) So it seems that you encounter delays in case if VS recompiles a large
subset of your solution
(and timestamps of output dlls => referenced dlls are changed accordingly).
However, from my experience
recompiling a large solution is such a time-consuming process that 10 sec
delay after it does not almost add
nothing. However, from your post I have to conclude that your solution recompiles
fast and
ReSharper's activity incurs a great overhead compared with VS build, is it
really true?
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> We'll consider that.
>>
>> Meantime, it seems that I forgot to clarify an
>> important
>> point: does that 10-20 sec delay happen after each
>> build
>> (that is, when you run Build Solution command) or
>> after each
>> actual rebuild (when output dlls do really change)?
Thats' right.
Yes.
My specific is that I have a large number of relatively small dll's with relative high count of small classes.
So compilation time is in the order of 30-60 secs, and then reloading dll's by resharper is order of 20-30 sec. To this may add that I am force to use currently only 2.8 Ghz Celeron with only 266 Mhz access to memory speed.
So it's really anoying also for the fact that reloading freezes VStudio. I guess that area may need optimization. Also this reloading could be done on separate low priority thread. So when I run my application after build or when I try to edit code again, resharper reloading impact will be minimal.
Thanks for this additional information.
Of course, it's not good that reloading dlls freezes VS, but in a regular
scenario,
referenced assemblies are reloaded very fast, so that's not a big issue.
Unfortunately,
the architecture of ReSharper 1.5 does not allow to do reloading in a separate
thread.
But we'll definitely work on improving this in the 2.0 version.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> 2) So it seems that you encounter delays in case if
>> VS recompiles a large
>> subset of your solution
>> ReSharper's activity incurs a great overhead compared
>> with VS build, is it
>> really true?
I think reloading of assemblies could be optimized. Its not normal that it takes about the same time as compilation itself.
I tried to use AddIn Manager to disable Resharper, but I found it annoying to wait while resharper loads at startup when I accidentaly press one of resharper shortcuts. Can I some how stop Resharper from starting automatically when it is disabled in AddIn manager?
We'll work on improving performance of assembly loading.
As for activating ReSharper when one of its shortcuts is pressed, unfortunately,
there is no way to disable it - this is how the VS works. It loads & activates
an add-in when
one of its commands is invoked.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> VS, but in a regular
>> scenario,
>> referenced assemblies are reloaded very fast, so
>> that's not a big issue.