Performance - Upgrade?

Hi all,

Mission : Speed up Resharper as much as possible.

Options : Dual CPU or real nasty and fast single CPU.

Regards,


9 comments
Comment actions Permalink

Hello chad,

we've appreciated a concise style of your message :), but could you please
elaborate
on the performance problems you're experiencing? In other words, what is
slow?

Thanks.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hi all,

Mission : Speed up Resharper as much as possible.

Options : Dual CPU or real nasty and fast single CPU.

Regards,



0
Comment actions Permalink

Hehe, thanks for the quick response mate :).

We have some 3000+ line c# forms that we work with and after a build getting
back to the source hangs the system for an annoying amount of time. Well,
even after opening them it takes a long time for the little box top right to
go green from white. I'm running a 2gig Athlon 64 and just want to speed up
things for a bit.

I know dual cpu can make a real difference if an application was written for
it else single cpu is the way to go.

Cheers and thanks for giving us "Develop with pleasure!" :D

"Dmitry Shaporenkov (JetBrains)" <dsha@jetbrains.com> wrote in message
news:c8a894d9d8a878c7dd00efaf3f27@news.intellij.net...

Hello chad,

>

we've appreciated a concise style of your message :), but could you please
elaborate
on the performance problems you're experiencing? In other words, what is
slow?

>

Thanks.

>
>

Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>> Hi all,
>>
>> Mission : Speed up Resharper as much as possible.
>>
>> Options : Dual CPU or real nasty and fast single CPU.
>>
>> Regards,
>>
>



0
Comment actions Permalink

Hello chad,

the process of code analysis (that draws red/yellow/green box at the top
right corder of the editor)
is performed in a dedicated separate thread, but it is designed in a way
that shouldn't affect user's
activity. In particular, it shouldn't prevent the user from editing code,
since the code analysis interrupts
each time the user presses a key or moves the cursor. The speed of code analysis
itself can, of course,
benefit from a faster system, but I'm not sure if dual CPU can make a big
difference here - may be faster single
CPU is enough. Generally, ReSharper is not a heavily multithreaded application,
and thus it will (presumably,
as unfortunately we have no experimental data) hardly benefit from a better
ability to run concurrent
threads in the system.

As for delays after build, we've heard of this problem but we have no reliable
way to repeat it. Could you
please describe what projects do you have in your solution. In particular,
do you have any C++ or VB projects?
ReSharper loads and parses output assemblies of the projects written in a
language whose sources it cannot parse,
so this is where those delays may come from.

In any case, you may want to take a look at ReSharper 2.0 EAP, and check
how it works for you from the
performance viewpoint as compared to 1.5.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hehe, thanks for the quick response mate :).

We have some 3000+ line c# forms that we work with and after a build
getting back to the source hangs the system for an annoying amount of
time. Well, even after opening them it takes a long time for the
little box top right to go green from white. I'm running a 2gig Athlon
64 and just want to speed up things for a bit.

I know dual cpu can make a real difference if an application was
written for it else single cpu is the way to go.

Cheers and thanks for giving us "Develop with pleasure!" :D

"Dmitry Shaporenkov (JetBrains)" <dsha@jetbrains.com> wrote in message
news:c8a894d9d8a878c7dd00efaf3f27@news.intellij.net...

>> Hello chad,
>>
>> we've appreciated a concise style of your message :), but could you
>> please
>> elaborate
>> on the performance problems you're experiencing? In other words, what
>> is
>> slow?
>> Thanks.
>>
>> Regards,
>> Dmitry Shaporenkov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>> Hi all,
>>>
>>> Mission : Speed up Resharper as much as possible.
>>>
>>> Options : Dual CPU or real nasty and fast single CPU.
>>>
>>> Regards,
>>>


0
Comment actions Permalink

19 Projects, no mix, all c#. But it's all good, I got my answer I was
looking for, single CPU it is. :p

And unfortunately I'm one of those people that don't have time to play the
beta game. Lol, should I cry of smile.



Anyhow, thanks a lot mate.



"Dmitry Shaporenkov (JetBrains)" <dsha@jetbrains.com> wrote in message
news:c8a894d9d93c88c7dda309d1f33f@news.intellij.net...

Hello chad,

>

the process of code analysis (that draws red/yellow/green box at the top
right corder of the editor)
is performed in a dedicated separate thread, but it is designed in a way
that shouldn't affect user's
activity. In particular, it shouldn't prevent the user from editing code,
since the code analysis interrupts
each time the user presses a key or moves the cursor. The speed of code
analysis itself can, of course,
benefit from a faster system, but I'm not sure if dual CPU can make a big
difference here - may be faster single
CPU is enough. Generally, ReSharper is not a heavily multithreaded
application, and thus it will (presumably,
as unfortunately we have no experimental data) hardly benefit from a
better ability to run concurrent
threads in the system.

>

As for delays after build, we've heard of this problem but we have no
reliable way to repeat it. Could you
please describe what projects do you have in your solution. In particular,
do you have any C++ or VB projects?
ReSharper loads and parses output assemblies of the projects written in a
language whose sources it cannot parse,
so this is where those delays may come from.

>

In any case, you may want to take a look at ReSharper 2.0 EAP, and check
how it works for you from the
performance viewpoint as compared to 1.5.

>
>

Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>> Hehe, thanks for the quick response mate :).
>>
>> We have some 3000+ line c# forms that we work with and after a build
>> getting back to the source hangs the system for an annoying amount of
>> time. Well, even after opening them it takes a long time for the
>> little box top right to go green from white. I'm running a 2gig Athlon
>> 64 and just want to speed up things for a bit.
>>
>> I know dual cpu can make a real difference if an application was
>> written for it else single cpu is the way to go.
>>
>> Cheers and thanks for giving us "Develop with pleasure!" :D
>>
>> "Dmitry Shaporenkov (JetBrains)" <dsha@jetbrains.com> wrote in message
>> news:c8a894d9d8a878c7dd00efaf3f27@news.intellij.net...
>>
>>> Hello chad,
>>>
>>> we've appreciated a concise style of your message :), but could you
>>> please
>>> elaborate
>>> on the performance problems you're experiencing? In other words, what
>>> is
>>> slow?
>>> Thanks.
>>>
>>> Regards,
>>> Dmitry Shaporenkov
>>> JetBrains, Inc
>>> http://www.jetbrains.com
>>> "Develop with pleasure!"
>>>> Hi all,
>>>>
>>>> Mission : Speed up Resharper as much as possible.
>>>>
>>>> Options : Dual CPU or real nasty and fast single CPU.
>>>>
>>>> Regards,
>>>>
>



0
Comment actions Permalink

Hello,

the process of code analysis (that draws
red/yellow/green box at the top
right corder of the editor)
is performed in a dedicated separate thread, but it
is designed in a way
that shouldn't affect user's
activity. In particular, it shouldn't prevent the
user from editing code,


In fact it prevents. When one sorce code is over 1000 lines of C# code then resharper is getting pretty slow. It consumes much CPU and there is not much left for user input. Maybe priority setting for this parsing thread could help.

As for delays after build, we've heard of this
problem but we have no reliable
way to repeat it. Could you
please describe what projects do you have in your
solution.


It is very easy. I have reproduced it verious times on many machines and on many projects. Just take ~50-80 separate DLL projects into one solution, add refferences not by project GUID but by DLL to one other. DLLs don't have to be very big, but the bigger they get the more delays happen as Resharper tries to reload them after they date is changed after build. Sometimes VS2003 build them very fast and Resharper takes forever to load them.

another problem that Resharper 1.5 looses track of types with such a solutions very often. And it displays errors where types does not match, however it displays same typoe names and compiler compiles code OK. And naturally autocomplete stops working, so resharper becomes pointless

To fight this situation i've started using 2.0 EAP and converted my projects to use refferences by projects GUID. But so far found only build 209 is usable: fast, stable and no false errors. Builds after that also are plagued with same problems loosing track of .NET types and slow.

Latest i've tried was build 218. I've heard reports that this loading after building is greatly improved in 218 with not GUID refferences, but autocomplete stops working too often on 218 and false errors are displayed.

It's a pitty that this great product is so unusable in big applications where it should come really handy

0
Comment actions Permalink

Perhaps the easiest way to reproduce this issue is to download the
Enterprise Library source and save it in a project folder somewhere close to
the root. I recommend using a path close to the root because the folders are
nested fairly deeply and may exceed the woefully inadequate 260-character
maximum path limit if you drop it into "My Documents\Visual Studio Projects"
or "My Documents\Visual Studio 2005\Projects". Finally, open
EnterpriseLibrary.sln in Visual Studio and go grab a cup of coffee. When the
project opens, Rebuild All, and wait a bit.

ReSharper 1.5 takes just shy over three minutes to load and save caches when
opening the solution. The interesting part is that once ReSharper shows the
dialog, it take just at one minute to load caches to reach 94% and CPU usage
is running around 70 to 80%. Once the text changes to Save Caches, the CPU
hits 100% and stays there for two minutes.

I'm not near a computer with ReSharper beta installed, so I can't give a
performance analysis on it at the moment.


"andrius@technopark.lt" <no_mail@jetbrains.com> wrote in message
news:20281466.1140505161588.JavaMail.javamailuser@localhost...

Hello,

>
>> the process of code analysis (that draws
>> red/yellow/green box at the top
>> right corder of the editor)
>> is performed in a dedicated separate thread, but it
>> is designed in a way
>> that shouldn't affect user's
>> activity. In particular, it shouldn't prevent the
>> user from editing code,
>

In fact it prevents. When one sorce code is over 1000 lines of C# code
then resharper is getting pretty slow. It consumes much CPU and there is
not much left for user input. Maybe priority setting for this parsing
thread could help.

>
>
>> As for delays after build, we've heard of this
>> problem but we have no reliable
>> way to repeat it. Could you
>> please describe what projects do you have in your
>> solution.
>

It is very easy. I have reproduced it verious times on many machines and
on many projects. Just take ~50-80 separate DLL projects into one
solution, add refferences not by project GUID but by DLL to one other.
DLLs don't have to be very big, but the bigger they get the more delays
happen as Resharper tries to reload them after they date is changed after
build. Sometimes VS2003 build them very fast and Resharper takes forever
to load them.

>

another problem that Resharper 1.5 looses track of types with such a
solutions very often. And it displays errors where types does not match,
however it displays same typoe names and compiler compiles code OK. And
naturally autocomplete stops working, so resharper becomes pointless

>

To fight this situation i've started using 2.0 EAP and converted my
projects to use refferences by projects GUID. But so far found only build
209 is usable: fast, stable and no false errors. Builds after that also
are plagued with same problems loosing track of .NET types and slow.

>

Latest i've tried was build 218. I've heard reports that this loading
after building is greatly improved in 218 with not GUID refferences, but
autocomplete stops working too often on 218 and false errors are
displayed.

>

It's a pitty that this great product is so unusable in big applications
where it should come really handy



0
Comment actions Permalink

I have a solution with ~25-30 projects in it (quite large solution), i am using the 2.0 EAP build 219 on vs2005, and I get constant out of memory exceptions from resharper just trying to load my solution.

In VS2003 with 1.5 it took a couple minutes to load the solution but was usable, and i liked the features quite a lot. I really want to be able to use it in vs2005.

My system is:
dual +2600 athlon MP's (~2.1ghz)
2gb ram
250gb raid 10 SATA drive system

So as you can see there is no reason for resharper to not be able to load my solution, my machine is no slouch. Unfortunately having a faster cpu or dual cpu will not fix your problems.

In it's current condition i guess i will have to uninstall again and go back to something else.


0
Comment actions Permalink

Hello Chris,

such a solution definitely should not be a killer for ReSharper. In fact,
ReSharper source base
we're constantly working on has > 60 projects, some of which are very large.
May be you have
some outstandingly large files?

Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I have a solution with ~25-30 projects in it (quite large solution), i
am using the 2.0 EAP build 219 on vs2005, and I get constant out of
memory exceptions from resharper just trying to load my solution.

In VS2003 with 1.5 it took a couple minutes to load the solution but
was usable, and i liked the features quite a lot. I really want to be
able to use it in vs2005.

My system is:
dual +2600 athlon MP's (~2.1ghz)
2gb ram
250gb raid 10 SATA drive system
So as you can see there is no reason for resharper to not be able to
load my solution, my machine is no slouch. Unfortunately having a
faster cpu or dual cpu will not fix your problems.

In it's current condition i guess i will have to uninstall again and
go back to something else.



0
Comment actions Permalink

Hello Chris,

such a solution definitely should not be a killer for
ReSharper. In fact,
ReSharper source base
we're constantly working on has > 60 projects, some
of which are very large.
May be you have
some outstandingly large files?

Nice to hear....
Sometimes I am working with files 5000 - 6000 lines of code, thenks to WebServices, Generated proxies, Regions, LLBL generated data access files with and stupid software architects...

BTW Build 229 is really nice. It lloks that speed is acceptable

0

Please sign in to leave a comment.