Hacker News Reader

Comment by jaked89 | Hacker News Reader

While the rewrite enabled faster development of the language as a whole, it also gradually destroyed the IDE's performance. The editor in VS 2019 is simply unworkable.

I blame this directly on the immutable AST. While a nice concept in theory, it causes too many allocations, and is cumbersome to work with.

I predict another rewrite in 2 or 3 years.

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 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#.

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 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 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).

> I blame this directly on the immutable AST. While a nice concept in theory, it causes too many allocations, and is cumbersome to work with.

This isn't a cause of performance problems you're seeing. What's most likely happening is that the overall size of your code has increased a lot over time, causing performance issues due to issues that have existed for a long time, but weren't being felt yet.

The issue that's most directly related to this is here: https://github.com/dotnet/roslyn/issues/40300

However, immutable vs. mutable isn't related to the issue I linked. It's just about keeping more data around than is (perhaps) necessary. You'd see the same issue with a mutable AST. If you're curious about specific work that's being tracked you can use this label: https://github.com/dotnet/roslyn/issues?q=is%3Aopen+is%3Aiss...

And if you submit reports via the VS Report a Problem tool, with the option to collect a diagnostic trace, you'll generate exactly the data needed to fix issues that you're facing. The team is very keen on addressing performance problems, especially if there's diagnostic data that can pinpoint the source of a problem.

> the overall size of your code has increased a lot over time, causing performance issues due to issues that have existed for a long time, but weren't being felt yet.

Not really. A simple empty project displays the same problems. You can try going back to 2017 right now with any project you're working on, you'll feel the difference instantly.

Intellisense simply takes longer to respond, and likewqise other editor functions.

Their feedback forums have hundreds of similar reports.

Interesting. I've observed the opposite, with VS 2017 often being unbearably slow in comparison as the codebase gets large. But I can appreciate that you may be experiencing the opposite. I highly recommend filing issues, especially if you can do so with a specific, reproducible problems. Those tend to get resolved quite quickly.

> Those tend to get resolved quite quickly.

The issues are getting resolved in the public bug trucker, pretty quickly indeed, typically saying "can't reproduce, won't fix", sometimes "not a bug, won't fix".

I'm not sure the software problems are getting resolved.

You can look through GH milestones to see specific issues fixed in results. For example, here are the 230 tracked items done for the VS 16.4 public release: https://github.com/dotnet/roslyn/milestone/53?closed=1

You can also see that there are many more resolved issues in previews of that public release: https://github.com/dotnet/roslyn/milestones?state=closed

So there are a _lot_ of legitimate problems being fixed and enhancements being added over pretty short periods of time.

When something is resolved as "no reproduction" or "not a bug", that's because there was an earnest attempt to reproduce an issue with the latest bits set to go out to a release with no reproduction, or something is truly by design (e.g., user files an issue because they would prefer a feature to do something different than it does today).

My experience might be irrelevant to Roslyn, I experienced these things when reporting Visual Studio bugs in general. Examples:

https://developercommunity.visualstudio.com/content/problem/... (BTW, people have been reporting that bug for years now)

https://developercommunity.visualstudio.com/content/problem/...

That is interesting and counter to my experience. Consider looking in to alternative causes (uninstalling plugins that may not be playing nicely with your particular version, background updates, etc.)

Have you replicated this issue on multiple machines?

If an immutable datastructure causes to many allocations surely that's an issue with the allocator rather than immutability?

I'm not familiar with this compiler but I'm currently writing a mostly immutable structure so I'm curious as to whether it's an issue.

It's not an issue. See here: https://news.ycombinator.com/item?id=22303220

The problem with immutability in a rapidly mutating environment is that the theory clashes with reality.

Anytime a leaf node changes, all its ancestors have to be replaced, instead of just updating the leaf in place. (I'm aware of the red-black node separation, but I believe that in practice most of the tree is constantly regenerated all the time).

I realized it when trying to write a complex analyzer. I had to replace the tree all the way up to the project level. If you combine different chunks of the tree, each with a slight change, you're forced to recreate each of those chunks.

This is extremely wasteful, and no wonder the IDE behaves so poorly.

Also, forgot to mention, that in some analyzers, even if you have no actual code change, the symbols change meaning, and then you're forced to recreate the tree regardless, because you can't change the node-symbol association.

I found that VS 2019 is faster than VS 2017. But VS 2019 with Resharper is a lot more slower than VS 2017 with resharper. I would blame resharper there, not VS. VS never felt that fast than right now.

Every VS release is one reason less to use Resharper.

The biggest reason IMO not to use ReSharper is actually Rider (so I don't use VS anymore either). You get all the ReSharper goodies, but inside an editor that's more nimble than vanilla VS.

If I learned anything from my Borland days was to only get my IDE tooling from the same factory that does the sausage, instead of always playing catch-up with the OS vendor tooling.

I just don't use ReSharper anymore and almost don't miss it. I tried Rider but don't use it anymore. I don't like the Intellij/Rider UI, defaults shortcuts are horrible, basic actions are hiding in submenu. In my opinion, Visual Studio UX is not great, but far better than JetBrains products.

I never had any issues with it, I guess because I keep myself away from JetBrains products as much as possible (have to endure them on Android).

Visual Studio is 32-bit and limited to about 3.5GB of RAM. The increasing functionality and solution sizes create bottlenecks in the processing.

This is a fundamental problem that for various (outdated and bad) reasons the team hasn't fixed. They've been refactoring components to run in separate processes but it's slow progress and still won't solve the main thread running out of memory anyway.

They kind of are already rewriting it, with VSCode + OmniSharp.

OmniSharp + VSCode uses Roslyn as well, so there's no rewrite going on here. But because VSCode is very different to VS - namely that it's a process host where language services run in entirely separate processes. In VS, things are a bit more complicated since lots of things run in the IDE process, but in the case of Roslyn, there are other processes spun up to run specific things.

VS Code is like 50% of VS capabilities.

VS2019 runs fast for me O.o

Reply on news.ycombinator.com