Good bye for now, resharper

Since installing 4.0, my vs 2008, sp1 had been unusable... IN task manager, it would show Vs grabbing almost a gig of memory.. R# was always complaining about "out of memory" errors even though I whave 4 gig and nothing else running...

Everything become unbearable.. Today, after reading about others issues with this, I uninstalled it and now VS is fine. It does NOT try and grab all the memory and the speed is back...

It has killer features, but only if they don't destroy the product it is supposed to enhance!

Harold

I'll try again later with a new version.

7 comments


"Harold Chattaway" <no_reply@jetbrains.com> wrote in message
news:19498200.189031217796931142.JavaMail.jive@app4.labs.intellij.net...

Since installing 4.0, my vs 2008, sp1 had been unusable... IN task
manager, it would show Vs grabbing almost a gig of memory.. R# was always
complaining about "out of memory" errors even though I whave 4 gig and
nothing else running...

>

Everything become unbearable.. Today, after reading about others issues
with this, I uninstalled it and now VS is fine. It does NOT try and grab
all the memory and the speed is back...

>

It has killer features, but only if they don't destroy the product it is
supposed to enhance!

>

Harold

>

I'll try again later with a new version.


I kind of having the same feeling, the Resharper slows down VS2008 a lot.

0

Hello Harold,

Have you tried the OutOfMemory Fix here: http://www.jetbrains.net/confluence/display/ReSharper/OutOfMemoryException+Fix

I know it has worked wonders for me.

~Andy

Since installing 4.0, my vs 2008, sp1 had been unusable... IN task
manager, it would show Vs grabbing almost a gig of memory.. R# was
always complaining about "out of memory" errors even though I whave 4
gig and nothing else running...

Everything become unbearable.. Today, after reading about others
issues with this, I uninstalled it and now VS is fine. It does NOT try
and grab all the memory and the speed is back...

It has killer features, but only if they don't destroy the product it
is supposed to enhance!

Harold

I'll try again later with a new version.



0

It would help the devs if you guys could say which build of R# you're running (and if it's not a most recent nightly, have you tried it?), and what kind of projects you're working on. Things which there seem to have been known problems with are older versions of R#, web-projects in general and some arrangements of files in particular, and projects/files with lots of C#3 extension methods.

My feeling is that there isn't an inevitable 'R# makes VS much slower' issue, but there are specific things which do cause problems which may or may not have been fixed since the release of R#4.0

Just saying 'it's slow, I'm not go to use it' may achieve the desired effect of making the R# guys feel bad, but it's not going to help them fix it for the rest of us.

When I first started to use R# (3) it had a catastrophic perf bug which made it completely unusable on my system - but that was fixed in a nightly, and wasn't the evidence of general terrible perf that I thought it was.

I do think JB are more careless of perf than they could be - their technique of apparently adding a finaliser to every single object is very expensive, they've been reluctant to stop a lot of disk logging, and just the other day, someone from JB was very glib about 1000's of registry reads a second, claiming that it didn't have much effect on perf. Yeah, right. However, the product performs OK for lots of people, including people like me who are very fussy about perf on our dev machines.

0

their technique of apparently adding a finaliser to every single object is very expensive


Not necessarily true, if they add GC.SuppressFinalize(this) in the Dispose() methods of their classes. I think JB folks are smart enough to have done that.

0

There's more expense to finalizable objects than just the GC generation bump which is prevented by that call, though.

For example, every finalizable object has to have a reference on the freachable queue, which adds cost to allocation and collection (regardless of whether SuppressFinalize then gets called at some point in the object's lifetime).

Maybe they compile all their spare finalizers out in full release versions, but I know that last time I attached a debugger to VS (which would have been running a nightly), there were 10s of thousands of finalizable objects, most of which had 'JetBrains' in their names...

0

No I had not tried the memory fix.. I will...
The install file I have has a date of 6/14/2008

And to the other comment about wanting to make the R# guys feel bad, thats ridiculous.. When I spent good money to buy this, I am the one feeling bad about it...

I am primarily working on Dotnetnuke sites configured as a website project. Large sites.

Harold

0

Harold,

If I were you, I would try a recent nightly build: http://www.jetbrains.net/confluence/display/ReSharper/ReSharper4.0Nightly+Builds

I believe there are some improvements to the performance of web projects since the version you apparently have.

0

Please sign in to leave a comment.