15 comments
Comment actions Permalink

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!"

After build with Visual Studio resharper ususes 100% CPU for about 30
sec. and then it is back to normal




0
Comment actions Permalink

Dmitry Shaporenkov wrote:

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!"

>> 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

0
Comment actions Permalink

1) Is the problem always reproducible?

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.

0
Comment actions Permalink

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?
>>

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.




0
Comment actions Permalink

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.

0
Comment actions Permalink

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?

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.




0
Comment actions Permalink

How many such references do you have?

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

0
Comment actions Permalink

I would like to propose to have a chekcbox in optionas to disable refferenced DLLs reloading after build.

0
Comment actions Permalink

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!"

I would like to propose to have a chekcbox in optionas to disable
refferenced DLLs reloading after build.




0
Comment actions Permalink

We'll consider that.

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.

0
Comment actions Permalink

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.
>>

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.




0
Comment actions Permalink

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.

0
Comment actions Permalink

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

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.




0
Comment actions Permalink

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?

0
Comment actions Permalink

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.

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?




0

Please sign in to leave a comment.