R# 4.5.1 slower than 4.5.0

I absolutely agree. 4.1 and later 4.5 were the first R# versions which were usable and 4.5.1 really isn't. Not only does it now throw exceptions at random intervals, it's soooooooo slooooooooow that I'm thinking about uninstalling it. I use a quad core 2 duo with 2GB ram and vs.net 2008 sp1, and ok, my solution is perhaps a bit big, but it's simply too slow now to be usable. The file analysis is not able to keep up (and looking at the CPU usage, it's not doing anything).

For example, when I type
List<SomeType> s = new _
and at '_' the caret is located, I don't always get the popup anymore, it's simply too slow. Hopefully they fix it. Perhaps they should use their other product ;)

I have gone back to Build 1231, which feels much faster than the release version (build 1274). of course there are also a few more bugs, but I can live with that for the time being.

did you try the latest build (1277) from the EAP pages (http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+4.5+Nightly+Builds)? I had similar problems with the VB editor which are gone with this build. Jetbrains has fixed some performance issues in this build.

Regaeds
Klaus

I tried the latest version, but it is still the same problem. Slows down more and more, after 1-2 hours, it is down to 2 secs per key stroke.

It is really disappointing to discover that an update (4.5) that was dedicated to speed is now again as slow as its predecessors.
Please, JetBrains, after all these years it should be clear that the usability of R# completely depends on its speed. And with 4.5.1 we are back where we started and maybe even worse.
Are you guys diving in to this soon or do we have to go back to 4.5.0?

Regards,

Patrick

EDIT: Well, tried the latest nightly build, but that one was even slower. Then tried to go back to 4.5.0, but that version does not work at all once you have 4.5.1 installed. So I guess I am stuck to restarting R# every hour. Would it be possible in the mean time to change the background image of the About box, 'cause it seems a bit cynical to me.

Hi,

I agree. That version seems a lot faster than the release build of 4.5.1.

Kind regards,
Henning Krause

"Klaus Luedenscheidt" <no_reply@jetbrains.com> wrote in message
news:30155208.175631249449382960.JavaMail.clearspace@app8.labs.intellij.net...

did you try the latest build (1277) from the EAP pages
(http://www.jetbrains.net/confluence/display/ReSharper/ReSharper4.5Nightly+Builds)?
I had similar problems with the VB editor which are gone with this build.
Jetbrains has fixed some performance issues in this build.

>

Regaeds
Klaus

>

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

I think I found the solution for the problem: After disabling the unit tests in R# options (which I don't use anyway), R#'s speed is back to what it was on 4.5.0. Horray!
Seems that jetbrains introducted a serious problem in their unit test component between 4.5.0 and 4.5.1.

going back to 4.5.0 was no problem for me. you just have to clear the R# cache after installing 4.5.0 over 4.5.1, then restart visual studio.

Hello Urs
Thank you for this information! Could you please enable unit testing back and try profiling this problem with dotTrace (http://www.jetbrains.com/profiler/download)? Please follow the following steps:
1. Download and install dotTrace 3.1
2. Start dotTrace, choose 'Profile Application', point dotTrace to Visual Studio executable (devenv.exe), make sure 'Performance profiling' mode is selected and 'Start profiling immediately' option is turned off
3. Press Start
4. Wait while Visual Studio starts, open your solution
5. Press 'Start Profiling' button on the 'Control Profiling' window, perform the actions which are slow with unit testing turned on for some time
6. Press 'Get Snapshot', save the resulting snapshot and send it to me (andrew.serebryansky[at]jetbrains.com)

I'm also very frustrated with the latest version   It is causing OutOfMemory exceptions on our machines and the memory of devenv quickly sits at 1.1 GIG.  We are running 2.0 Ghz Dual Core machines with Vista and 4 GIG RAM.  The solution has 22 projects and worked fine with the previous version.  I was able to keep VS open for a few days.  Now I need to close VS at least 2-3 times a day and the performance in the IDE is still sluggish.  What is the solution?  To revert to the initial 4.5 build?  What specific version number and what other steps do I need to do to get back the 4.5.0 speed?

Perhaps just a FYI in terms of the reported memory usage.  I uninstalled R# to do some tests and discovered that without R# my devenv.exe still ended up at just over a 1 GIG after compiling my solution.  I created a new solution and added all the projects and after an initial load and compile devenv.exe ended up with only 220MB!  The problem turned out to be that I had a .suo file for the solution that was 132MB big.  Deleting this file solved the issue for me and I am so glad that I can again install R# (Build 1231 though ) to get my solution compiling without the OutOfMemoryException   Seems that, for me, on average using R# adds around 250MB cause as after installing Build 1231 and compiling I end up with around 490MB for devenv.exe.

Thanks

urs.eichmann wrote:

going back to 4.5.0 was no problem for me. you just have to clear the R# cache after installing 4.5.0 over 4.5.1, then restart visual studio.

Tried that, but the exceptions kept coming. Hopefully there will be a proper release soon.

I would like to install 4.5.0 instead of  4.5.1. Who can tell me the download address of 4.5.0?

Thanks a lot!

IMHO it is more likely to have to do with LINQ expressions. Files which have LINQ expressions take a very long time to analyze. Not to mention the intellisense for LINQ expressions which sometimes takes ages to complete and very often no suggestion appears at all. The more LINQ expressions I work on the sooner the lag appears.
I have to mention that I use O/R mapper LLBLGenPro as Linq provider, and I truly don't know what R# has to parse from the generated DAL code. The generated DAL code is part of the solution and is quite big.

Hey Patrick :)

I don't think the generated DAL is really a significant issue, because I get the slowdowns in C# code of the designer, with just a few linq to object queries somewhere in the code (but not in the code I worked on).

It's true that solutions with a lot of classes take a longer time to analyze but with v4.5.0, this was much faster than with v4.5.1. Our linq to llblgen pro unit tests solution for example was dog slow with v4.5.1. but much faster to work with with v4.5.0.

It's true that solutions with a lot of classes take a longer time to analyze but with v4.5.0, this was much faster than with v4.5.1. Our linq to llblgen pro unit tests solution for example was dog slow with v4.5.1. but much faster to work with with v4.5.0.

Hi Frans,

I agree with you that editing in 4.5.0 was much faster on the same project (so also on the same DAL). But when you type in Linq queries there was also in 4.5.0 a serious almost unworkable lag. Well, I could live with that in 4.5.0 and I can live with that in 4.5.1, but maybe there is, after working on a Linq query, some cleanup not done in 4.5.1 which was done in 4.5.0 which causes the editing after that to keep being slow.
Just my two cents...
I am also curious why R# is taking so long when parsing Linq queries while it does not have any performance issues when parsing code that uses the Entity, Collection, etc. classes directly. The code base is the same, so IMO it must have something to do with analyzing Linq.

Patrick

I think the biggest problem is to 'fix' the code (which is in incompilable state when you write the query) so it's compilable to a form which is understandable. R# has the same kind of problems to a lesser extend when you type a } too many which for example cuts off the code below it: instead of marking the extra } as wrong (as VS.NET does), it marks the cut-off code as wrong.

Personally I find R#'s linq intellisense support not really worth the effort: it most of the time is in my way:
from o in metaData.Order
where o_
sometimes, when I press . at the _ spot, I get 'object' inserted. Furthermore, when I type:
from o in metaData.Order
where // some filter
select new_

when I press space at the _ spot, I get the first type in the intellisense list inserted instead of a space so I can type an anonymous type. Perhaps the descriptions aren't exactly accurate above, (from memory ;)), they're at least areas where a lot of things could be improved, as it now has no clue what's in scope and what's not. For example the 'o' in the first query is a parameter/variable in the query, so the shortcut to 'object' should take a backseat.

Hello Frans,

I have tried to reproduce performance issue on demo project from LLBLGenPro
site. All seems to be work rather faster. Could you please try to reproduce
slowness on example project which could be download from http://www.llblgen.com/pages/examples.aspx?

Otherwise you can attach our profiling tool DotTrave and take a performance
snapshot.

Thanks in advance.

--
Kirill Falk
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I think the biggest problem is to 'fix' the code (which is in
incompilable state when you write the query) so it's compilable to a
form which is understandable. R# has the same kind of problems to a
lesser extend when you type a } too many which for example cuts off
the code below it: instead of mar

king the extra } as wrong (as VS.NET does), it marks the cut-off code
as wrong.

Personally I find R#'s linq intellisense support not really worth the
effort: it most of the time is in my way:

from o in metaData.Order

where o_

sometimes, when I press . at the _ spot, I get 'object' inserted.
Furthermore, when I type:

from o in metaData.Order

where // some filter

select new_

when I press space at the _ spot, I get the first type in the
intellisense list inserted instead of a space so I can type an
anonymous type. Perhaps the descriptions aren't exactly accurate
above, (from memory ;)), they're at least areas where a lot of things
could be improved, as it now has no clue
what's in scope and what's not. For example the 'o' in the first
query is a parameter/variable in the query, so the shortcut to
'object' should take a backseat.
---
Original message URL:
http://www.jetbrains.net/devnet/message/5243428#5243428

Kirill: I've gone back to v4.5.0 a week ago, so I can't test it at the moment. Perhaps Patrick can?

I don't know how big the database / class library was you tested it on. When I use AdventureWorks, (93 entities) it's already not really usable (also in v4.5.0). The main issue is that intellisense should pop up after 100ms, but it takes much longer than that, but the weird thing is that it's not always as slow, and sometimes intellisense popup also has a delay in other areas of the code (not linq queries), e.g. simple: SomeType somename = new_
and when I press SPACE at _, the intellisense popup simply doesn't appear, I have to re-try this at that moment. It's not always happening so I can't point to an exact setup, it just happens randomly. I have a quad core 2 duo proc and 2GB ram (desktop) so it's not the hardware.

File analysis is simply too slow in 4.5.1, already in a file with 1000 lines. I think you can test that with whatever file you open which is > 1000 lines. 4.5.1 is much slower than 4.5.0, so much so that analysis actually never comes back within a reasonable time frame (e.g. you type some lines, it reanalyses, it shows the result after a second or 2-3). No excessive cpu consumption is going on at that moment, so I don't  know what resharper is doing, but it's not pushing the limits at all.

Would you please tell me where to download a 4.5.0 version to install?

I really want to install it instead of 4.5.1

Thank you very much.

FransBouma wrote:

Kirill: I've gone back to v4.5.0 a week ago, so I can't test it at the moment. Perhaps Patrick can?

Kirill, I have mailed you a trace file of 91 MB. I hope it didn't crash your mailbox

Patrick

Hello Patrick,

Could you mail me directly to Kirill.Falk@jetbrains.com. I'll send you
ftp link for uploading big files.

--
Kirill Falk
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

FransBouma wrote:
>
> Kirill: I've gone back to v4.5.0 a week ago, so I can't test it at the
> moment. Perhaps Patrick can?
>
>

Kirill, I have mailed you a trace file of 91 MB. I hope it didn't
crash your mailbox
Patrick

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