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