5.1.2 performance

I've been using R# since V1.5 and have always accepted that it slow VS down but wasn't sure by how much.  Having just built myself a shiny new quad core system I decided to do a few comparative tests on VS.  I'm afraid my general conclusion is that having R# enabled on a dual core CPU slows down VS starting, solution load and compiling by 100%.  On a quad core VS starting is slowed by 100%, with solution load and compiling slowed by 50%.

Here are my timings:

System A: Dual core 6850, 8GB, Win 7 64 bit
System B: Quad core i760, 8GB, Win 7 64 bit


VS 2008 startup times
  System A:  4 or 5 seconds (R# suspended)
  System A:  10 seconds (R# resumed)
  System B:  3 or 4 seconds (R# suspended)
  System B:  7-8 seconds (R# resumed)
VS  2008 solution load times
  System A: 18-20 seconds (R# suspended)
  System A: 30-35+ seconds (R# resumed) (longer until R# finishes processing source code)
  System B: 9-10 seconds (R# suspended)
  System B: 15+ seconds (R# resumed) (longer until R# finished processing source)
VS  2008 solution rebuild times
  System A: 25-28 seconds (R# suspended) (max CPU 100%)
  System A: 55 seconds (R# resumed) (max CPU 100%)
  System B: 20 seconds (R# suspended) (max CPU 58%)
  System B: 30 seconds (R# resumed) (max CPU 95%)

I'm not about to ditch R#, the benefits are too great, but I'm slightly shocked at these figures.

At least I'm going to get some use out of all four cores :-)

Are things going to improve in R# 6?  And when can we expect to see the EAP?

Phil

23 comments
Comment actions Permalink

I'm a fan of R# since Release 1.0. I do agree with Philip that the performance decrease with every new release. O.K. there is a lot more functionality in the current release for which i accept a slowdown. I load a solution normally once a day so it don't matter if it takes one or two minutes. The increase of compile time is more critical for me.

Additionally the memory consumption is a problem. This morning i had an expierience with the VB solution i'm currently working on. After less than half an our the Virtual Size of VS was around 1,4 GB and the Working Set Size reaches 900 MB. The result was an OutOfMemoryException inside R#. I have to maintain several VB solutions. Depending on the size of the solution and the size of the codefiles i'm editing such Exceptions occurs former or later. And if i don't get exceptions i notice a significant slowdown of the editor over the time.

I know that such issues are hard to track down. When you take a look at the discussions about performance and memory here in the community you can see that it is a very important issue.

As christmas is around the corner my wish is that the Jetbrains team focus more on performance, memory and stability than on new features for the next R# release.

Regards
Klaus

0
Comment actions Permalink

Hello Philip,

What kind of times would you consider normal? Thank you!

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

I've been using R# since V1.5 and have always accepted that it slow VS
down but wasn't sure by how much.  Having just built myself a shiny
new quad core system I decided to do a few comparative tests on VS.
I'm afraid my general conclusion is that having R# enabled on a dual
core CPU slows down VS starting, solution load and compiling by 100%.
On a quad core VS starting is slowed by 100%, with solution load and
compiling slowed by 50%.

Here are my timings:

System A: Dual core 6850, 8GB, Win 7 64 bit
System B: Quad core i760, 8GB, Win 7 64 bit
VS 2008 startup times
System A:  4 or 5 seconds (R# suspended)
System A:  10 seconds (R# resumed)
System B:  3 or 4 seconds (R# suspended)
System B:  7-8 seconds (R# resumed)
VS  2008 solution load times
System A: 18-20 seconds (R# suspended)
System A: 30-35+ seconds (R# resumed) (longer until R# finishes
processing source code)
System B: 9-10 seconds (R# suspended)
System B: 15+ seconds (R# resumed) (longer until R# finished
processing source)
VS  2008 solution rebuild times
System A: 25-28 seconds (R# suspended) (max CPU 100%)
System A: 55 seconds (R# resumed) (max CPU 100%)
System B: 20 seconds (R# suspended) (max CPU 58%)
System B: 30 seconds (R# resumed) (max CPU 95%)
I'm not about to ditch R#, the benefits are too great, but I'm
slightly shocked at these figures.
At least I'm going to get some use out of all four cores :)
Are things going to improve in R# 6?  And when can we expect to see
the EAP?
Phil

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



0
Comment actions Permalink

Hello Klaus,

What version of ReSharper are you currently using? Thank you!

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

I'm a fan of R# since Release 1.0. I do agree with Philip that the
performance decrease with every new release. O.K. there is a lot more
functionality in the current release for which i accept a slowdown. I
load a solution normally once a day so it don't matter if it takes one
or two minutes. The increase of compile time is more critical for me.

Additionally the memory consumption is a problem. This morning i had
an expierience with the VB solution i'm currently working on. After
less than half an our the Virtual Size of VS was around 1,4 GB and the
Working Set Size reaches 900 MB. The result was an
OutOfMemoryException inside R#. I have to maintain several VB
solutions. Depending on the size of the solution and the size of the
codefiles i'm editing such Exceptions occurs former or later. And if i
don't get exceptions i notice a significant slowdown of the editor
over the time.

I know that such issues are hard to track down. When you take a look
at the discussions about performance and memory here in the community
you can see that it is a very important issue.

As christmas is around the corner my wish is that the Jetbrains team
focus more on performance, memory and stability than on new features
for the next R# release.

Regards
Klaus
---
Original message URL:
http://devnet.jetbrains.net/message/5279741#5279741



0
Comment actions Permalink

I'm using the latest EAP build 1760. Please note my separate posting about OutOfMemoryExceptions.

Regards
Klaus


0
Comment actions Permalink

Andrey,

I'm not sure what I would consider 'normal', I was just surprised at the effect R# has, especially on compile times.  This is really frustrating if you have to use a lower powered machine.  The build time I gave below for a particular ASP.NET project is 165 seconds with R# on a laptop I need to use sometimes.

What is R# doing to cause the slow down in compile times?  Would it make sense for R# to move whatever it's doing to after the build has completed?

Phil

0
Comment actions Permalink

I've been thinking about this a bit more.  My (naive) expectations are:

1) that R# should not slow VS startup times by much, if at all.  However since this is a one off hit it's not really a problem.

2) that R# will slow solution load times.  It's got to parse the source and load its caches.

3) that R# should not slow compile times.  This is what don't understand.  I'm sure there are good reasons, but (I assume) R# parses all the source and loads its caches up front in 2).  Then as we edit the source R# is continuously updating its caches etc. So what's happening to slow compile times?

Phil

0
Comment actions Permalink

Hello Philip,

Regarding your expectations:
1) ReSharper is a complex managed add-on for Visual Studio. This means that
at Visual Studio startup, ReSharper assemblies must be jitted and loaded,
ReSharper must load its global settings and initialize internal systems which
manage Visual Studio integration etc (not solution-related). We do our best
to make this process as short as possible, but I'm afraid there's no way
we can make ReSharper take zero time at startup
3) ReSharper should not interfere with the build process itself, but it can
make the process slower. It constantly synchonizes with changes (for instance
when  some files get re-generated during build process ReSharper must re-analyze
them) which can increase the HDD/CPU utilization, which in turn can hamper
the build speed. If you've encountered a solution that builds really slow
with ReSharper enabled, it would be great if you could take a performance
snapshot of this behavior following the instructions under http://confluence.jetbrains.net/display/ReSharper/ReSharperPerformanceProfiling+Instructions
and upload it to ftp://ftp.intellij.net/.uploads/, so that we could take
a closer look at this problem.

Thank you! 

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

I've been thinking about this a bit more.  My (naieve) expectations
are:

1) that R# should not slow VS startup times by much, if at all.
However since this is a one off hit it's not really a problem.

2) that R# will slow solution load times.  It's got to parse the
source and load its caches.

3) that R# should not slow compile times.  This is what don't
understand.  I'm sure there are good reasons, but (I assume) R# parses
all the source and loads its caches up front in 2).  Then as we edit
the source R# is continuously updating its caches etc. So what's
happening to slow compile times?

Phil

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



0
Comment actions Permalink

Andrey,

I have created a snapshot (184Mb zipped) but I'm unable to upload it to your ftp site.

I can open ftp://ftp.intellij.net/.uploads/ in IE, but using Page|Open FTP site in windows explorer fails.

Connecting via ftp util requires username/password.

Further to my previous posts, I now realise that the problem seem to be specifically with a solution consisting of three web sites (in VB.NET).

I tried similar tests with a larger C# only solution, with no ASP.NET content, and this time there is essentially no difference in solution load or compile times with R# enabled or disabled.

Regards,

Phil

0
Comment actions Permalink

with VB solutions i always have more performance problems as with C# solutions. Beneath the R# analysis process VB sources are permanetly compiled in background. My assumption is, that there are concurrency problems between the compiler task and the R# analyzer task under some circumstances. Also in VB the performance of VS depends significant on the size of the source files (My expierience is that they should have < 5.000 lines of code).

Regards
Klaus

0
Comment actions Permalink

Hello Philip,

Try using some third-party ftp client (such as FileZilla for instance). The
.uploads folder has high securiy restrictions, so its contents are not visible
for external users and it accepts only upload requests. Thank you!

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

Andrey,

I have created a snapshot (184Mb zipped) but I'm unable to upload it
to your ftp site.

I can open ftp://ftp.intellij.net/.uploads/ in IE, but using Page|Open
FTP site in windows explorer fails.

Connecting via ftp util requires username/password.

Further to my previous posts, the problem seem to be specifically with
a solution consisting of three web sites (in VB.NET).

I tried similar tests with a larger C# only solution, with no ASP.NET
content, and this time there is essentially no difference in
solution load or compile times.

Regards,
Phil
---
Original message URL:
http://devnet.jetbrains.net/message/5280024#5280024




0
Comment actions Permalink

I have uploaded file profile2.7z

Phil

0
Comment actions Permalink

Hello Philip,

Thank you! I'll take a look at it and will write back with more info.

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

I have uploaded file profile2.7z

Phil

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



0
Comment actions Permalink

Hello Philip,

BTW, are there any plugins under ReSharper | Plugins... in your installation?
Thank you!

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

I have uploaded file profile2.7z

Phil

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



0
Comment actions Permalink

Hello Philip,

Sorry for delayed response! It looks like the build process may be slown
down by some ReSharper components that trigger when something is copied into
bin directory. We will try improving those components, so that they do not
impose such impact on build times. As to statup time, do you have dotCover
or dotTrace products installed? Thank you!

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

No, none.

Phil

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



0
Comment actions Permalink

Yes I have dotCover.  Disabling dotCover does seem to shave a couple of seconds off startup time.

0
Comment actions Permalink

Hello Philip,

It looks like dotCover also contributes to overall Visual Studio startup
time. Could you please suspend dotCover under Tools | Options | dotCover
| General and check if this speeds up VS startup? Thank you!

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

Yes I have dotCover.

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



0
Comment actions Permalink

Andrey,  yes disabling dotCover reduces startup time by about two seconds.

Phil

0
Comment actions Permalink

The memory consumption is more a problem for me. I have to work with a
relatively large website with several additional DLL projects attached to
the solution. After working on the project for a couple of hours or so I
have to shut down Visual Studio 2008 because it gets "Out of memory"
exceptions during the build phase. Using Resharper_ToggleSuspended in this
case doesn't help (perhaps because the memory is so fragmented?). This is on
a VMWare virtual machine running Windows Server 2003 x86 with 3.5GB memory.
I would move it to my physical computer (Windows 7 x64 with 12GB memory) but
our VPN won't run on anything more modern than Windows XP/Windows Server
2003.

"Klaus Luedenscheidt"  wrote in message
news:32133612.295901291622138617.JavaMail.devnet@domU-12-31-39-18-36-57.compute-1.internal...

I'm a fan of R# since Release 1.0. I do agree with Philip that the
performance decrease with every new release. O.K. there is a lot more
functionality in the current release for which i accept a slowdown. I load a
solution normally once a day so it don't matter if it takes one or two
minutes. The increase of compile time is more critical for me.

Additionally the memory consumption is a problem. This morning i had an
expierience with the VB solution i'm currently working on. After less than
half an our the Virtual Size of VS was around 1,4 GB and the Working Set
Size reaches 900 MB. The result was an OutOfMemoryException inside R#. I
have to maintain several VB solutions. Depending on the size of the solution
and the size of the codefiles i'm editing such Exceptions occurs former or
later. And if i don't get exceptions i notice a significant slowdown of the
editor over the time.

I know that such issues are hard to track down. When you take a look at the
discussions about performance and memory here in the community you can see
that it is a very important issue.

As christmas is around the corner my wish is that the Jetbrains team focus
more on performance, memory and stability than on new features for the next
R# release.

Regards
Klaus

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

0
Comment actions Permalink

With the Builds after 1760 i don't have to "OutOfMemory" problem any more. The memory consumption is always high (around 1GB virtual size) but this didn#t cause any problems for me. It seems to me that R# claims as much memory as possible to be fast. On my laptop with Windows 7 64Bit and 4GB main memory my Visual Studio 2010 claims up to 3GB

Regards
Klaus

0
Comment actions Permalink

Hello Greg,

What's the exact version of ReSharper? How big is your solution (how many
projects/classes/web forms/controls are there)? How big is the managed memory
usage reported by ReSharper in the Visual Studio status bar? Thank you!

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

The memory consumption is more a problem for me. I have to work with a
relatively large website with several additional DLL projects attached
to the solution. After working on the project for a couple of hours or
so I have to shut down Visual Studio 2008 because it gets "Out of
memory" exceptions during the build phase. Using
Resharper_ToggleSuspended in this case doesn't help (perhaps because
the memory is so fragmented?). This is on a VMWare virtual machine
running Windows Server 2003 x86 with 3.5GB memory. I would move it to
my physical computer (Windows 7 x64 with 12GB memory) but our VPN
won't run on anything more modern than Windows XP/Windows Server 2003.

"Klaus Luedenscheidt"  wrote in message
news:32133612.295901291622138617.JavaMail.devnet@domU-12-31-39-18-36-5
7.compute-1.internal...

I'm a fan of R# since Release 1.0. I do agree with Philip that the
performance decrease with every new release. O.K. there is a lot more
functionality in the current release for which i accept a slowdown. I
load a solution normally once a day so it don't matter if it takes one
or two minutes. The increase of compile time is more critical for me.

Additionally the memory consumption is a problem. This morning i had
an expierience with the VB solution i'm currently working on. After
less than half an our the Virtual Size of VS was around 1,4 GB and the
Working Set Size reaches 900 MB. The result was an
OutOfMemoryException inside R#. I have to maintain several VB
solutions. Depending on the size of the solution and the size of the
codefiles i'm editing such Exceptions occurs former or later. And if i
don't get exceptions i notice a significant slowdown of the editor
over the time.

I know that such issues are hard to track down. When you take a look
at the discussions about performance and memory here in the community
you can see that it is a very important issue.

As christmas is around the corner my wish is that the Jetbrains team
focus more on performance, memory and stability than on new features
for the next R# release.

Regards
Klaus
---
Original message URL:
http://devnet.jetbrains.net/message/5279741#5279741



0
Comment actions Permalink

I was using build 1764 and other builds from the 5.1.2 bug-fix builds page
and it was somewhat tolerable with the 5.1.2 bug-fix builds, meaning I might
have to restart Visual Studio a few times once or twice a day when I
encountered out of memory exceptions when building the solution.

The license on the bug-fix builds expired at some point after Christmas and
it wouldn't take my 5.0 license key, so I dropped back to ReSharper 5.1.1
production release and started getting out of memory exceptions after
something like three or six builds with minor changes in between each build.
I also noticed today ReSharper had one of the files locked during the build
process, so I cancelled the build, disabled ReSharper, and rebuilt the
solution.

The solution contains one website (roughly 320 aspx pages in 4 megs, 340
code files in 5 megs) and seven class library projects (roughly 527 code
files in 9 megs).

I'll get the memory statistics from ReSharper tomorrow when I'm back at
work. I might try today's 5.1.2 release candidate as well if the license is
valid with that one.

I also have the dotCover and dotTrace plug-ins installed.

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

Hello Greg,

What's the exact version of ReSharper? How big is your solution (how many
projects/classes/web forms/controls are there)? How big is the managed
memory
usage reported by ReSharper in the Visual Studio status bar? Thank you!

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

The memory consumption is more a problem for me. I have to work with a
relatively large website with several additional DLL projects attached
to the solution. After working on the project for a couple of hours or
so I have to shut down Visual Studio 2008 because it gets "Out of
memory" exceptions during the build phase. Using
Resharper_ToggleSuspended in this case doesn't help (perhaps because
the memory is so fragmented?). This is on a VMWare virtual machine
running Windows Server 2003 x86 with 3.5GB memory. I would move it to
my physical computer (Windows 7 x64 with 12GB memory) but our VPN
won't run on anything more modern than Windows XP/Windows Server 2003.

>

"Klaus Luedenscheidt"  wrote in message
news:32133612.295901291622138617.JavaMail.devnet@domU-12-31-39-18-36-5
7.compute-1.internal...

>

I'm a fan of R# since Release 1.0. I do agree with Philip that the
performance decrease with every new release. O.K. there is a lot more
functionality in the current release for which i accept a slowdown. I
load a solution normally once a day so it don't matter if it takes one
or two minutes. The increase of compile time is more critical for me.

>

Additionally the memory consumption is a problem. This morning i had
an expierience with the VB solution i'm currently working on. After
less than half an our the Virtual Size of VS was around 1,4 GB and the
Working Set Size reaches 900 MB. The result was an
OutOfMemoryException inside R#. I have to maintain several VB
solutions. Depending on the size of the solution and the size of the
codefiles i'm editing such Exceptions occurs former or later. And if i
don't get exceptions i notice a significant slowdown of the editor
over the time.

>

I know that such issues are hard to track down. When you take a look
at the discussions about performance and memory here in the community
you can see that it is a very important issue.

>

As christmas is around the corner my wish is that the Jetbrains team
focus more on performance, memory and stability than on new features
for the next R# release.

>

Regards
Klaus
---
Original message URL:
http://devnet.jetbrains.net/message/5279741#5279741


0
Comment actions Permalink

Hello Greg,

If you have a license for ReSharper 5, it should work with 5.1.2 builds as
well. If it doesn't please contact me through andrew dot serebryansky at
jetbrains dot com with your license details (or license certificate #). Thank
you!

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

I was using build 1764 and other builds from the 5.1.2 bug-fix builds
page and it was somewhat tolerable with the 5.1.2 bug-fix builds,
meaning I might have to restart Visual Studio a few times once or
twice a day when I encountered out of memory exceptions when building
the solution.

The license on the bug-fix builds expired at some point after
Christmas and it wouldn't take my 5.0 license key, so I dropped back
to ReSharper 5.1.1 production release and started getting out of
memory exceptions after something like three or six builds with minor
changes in between each build. I also noticed today ReSharper had one
of the files locked during the build process, so I cancelled the
build, disabled ReSharper, and rebuilt the solution.

The solution contains one website (roughly 320 aspx pages in 4 megs,
340 code files in 5 megs) and seven class library projects (roughly
527 code files in 9 megs).

I'll get the memory statistics from ReSharper tomorrow when I'm back
at work. I might try today's 5.1.2 release candidate as well if the
license is valid with that one.

I also have the dotCover and dotTrace plug-ins installed.

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

Hello Greg,

What's the exact version of ReSharper? How big is your solution (how
many
projects/classes/web forms/controls are there)? How big is the managed
memory
usage reported by ReSharper in the Visual Studio status bar? Thank
you!
Andrey Serebryansky
Senior Support Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>> The memory consumption is more a problem for me. I have to work with
>> a relatively large website with several additional DLL projects
>> attached to the solution. After working on the project for a couple
>> of hours or so I have to shut down Visual Studio 2008 because it gets
>> "Out of memory" exceptions during the build phase. Using
>> Resharper_ToggleSuspended in this case doesn't help (perhaps because
>> the memory is so fragmented?). This is on a VMWare virtual machine
>> running Windows Server 2003 x86 with 3.5GB memory. I would move it to
>> my physical computer (Windows 7 x64 with 12GB memory) but our VPN
>> won't run on anything more modern than Windows XP/Windows Server
>> 2003.
>>
>> "Klaus Luedenscheidt"  wrote in message
>> news:32133612.295901291622138617.JavaMail.devnet@domU-12-31-39-18-36-
>> 5 7.compute-1.internal...
>>
>> I'm a fan of R# since Release 1.0. I do agree with Philip that the
>> performance decrease with every new release. O.K. there is a lot more
>> functionality in the current release for which i accept a slowdown. I
>> load a solution normally once a day so it don't matter if it takes
>> one or two minutes. The increase of compile time is more critical for
>> me.
>>
>> Additionally the memory consumption is a problem. This morning i had
>> an expierience with the VB solution i'm currently working on. After
>> less than half an our the Virtual Size of VS was around 1,4 GB and
>> the Working Set Size reaches 900 MB. The result was an
>> OutOfMemoryException inside R#. I have to maintain several VB
>> solutions. Depending on the size of the solution and the size of the
>> codefiles i'm editing such Exceptions occurs former or later. And if
>> i don't get exceptions i notice a significant slowdown of the editor
>> over the time.
>>
>> I know that such issues are hard to track down. When you take a look
>> at the discussions about performance and memory here in the community
>> you can see that it is a very important issue.
>>
>> As christmas is around the corner my wish is that the Jetbrains team
>> focus more on performance, memory and stability than on new features
>> for the next R# release.
>>
>> Regards
>> Klaus
>> ---
>> Original message URL:
>> http://devnet.jetbrains.net/message/5279741#5279741


0

Please sign in to leave a comment.