Hacker News Reader

Comment by alkonaut | Hacker News Reader

I had to ditch ReSharper to get to 2019 because together with the performance of the IDE itself, it just wasn't usable. R# ate gigs of Ram and Roslyn does the same. It's not surprising since they basically do the same thing, in managed code! But I can't pay the CPU time and memory to analyze my code TWICE on every edit. I also suspect things like switching build configuration offers thousands of opportunities to have some IDE widget hold references to old compilation data structures which are never garbage collected. On the bright side at least 2019 works pretty well without R#.

View on HN

> I had to ditch ReSharper to get to 2019 because together with the performance of the IDE itself, it just wasn't usable. R# ate gigs of Ram and Roslyn does the same. It's not surprising since they basically do the same thing, in managed code! But I can't pay the CPU time and memory to analyze my code TWICE on every edit.

I'm holding off on 2019 as much as I can. Between 'forcing' an upgrade for .NET Core 3.0 and the fact Resharper slows it down too much, I decided to give Rider a try.

I'm finding myself not missing VS a whole lot; on one hand Rider is taking way more RAM to start and load, but it stays pretty constant after the first debug session, winds up staying under VS for memory on longer loads (Especially if I've got multiple solutions open) and it's smoother than VS the whole time.

Is Rider 64-bit?

It is, but that's not too relevant, as the ReSharper component runs in another process (but that's managed code as well, so probably also runs as a 64-bit process).

I'm not using ReSharper, and never have. The editor simply gets slower every version, and now it's come to the point where I seriously consider downgrading.

I did the exact opposite: I migrated to Rider, an IDE built around ReSharper. In my experience, it is much faster than VS2019 for my use case (including a huge monolith with hundreds of projects)

I highly suggest giving Rider (also by JetBrains) a try. They run most things in separate processes/threads instead of running everything in the UI thread like VS does. It's almost a drop-in replacement.

NB: It's not VS that's forcing ReSharper to run in the same process. It's JetBrains refusing to listen to the VS team on how to build VS extensions that need plenty of resources since 2008 ... (they're finally considering it as of summer 2019, I think).

Reply on news.ycombinator.com