[phillipcarter]

> If you are having to fight with VS, then you may not be using it for one of its main use cases.

So I worked on VS tooling for a few years and I'm proud of what me and my peers achieved, but I don't think this is the right perspective. People should not be surprised by the behavior of their tools, and they should not be frustrated by random freezes or crashes all of the time. What the person you're replying to has experienced is very real - I saw it come up again and again and again in reports - and I hope that things improve for them with subsequent releases.

VS 2022 is a fantastic new release (64-bit solves so many perf and user-perceived reliability issues), but there is so much more to go. VS still relies on a very very old COM-based UI model with one of the most convoluted and complex threading models to manage it that I've ever seen. It's so easy for any little component to mess things up, hang the UI, and make someone have a terrible experience. I know folks on the inside are working to improve this dramatically (they know roughly how to do it), but it's a long road ahead.

[SantiagoElf]

You should be very proud. I remember the early .NET 2.0/3.0 days where you had to have ReSharper installed and it made VS almost unusable. Nowadays (the last 5-6 years) I use Visual Studio without any third party extensions - it's a blast!

I believe Visual Studio to be one of the crown jewels of Microsoft.

[ripley12]

I'm not sure you can comment on this, but: any idea what the long-term plan is for UI in Visual Studio?

WPF has been more-or-less abandoned by the Windows team, and that's a little scary since VS uses WPF so much...

[phillipcarter]

I won't speculate on things, but I will say that WPF is far from abandoned: https://github.com/dotnet/wpf/blob/main/roadmap.md

[ripley12]

From the outside it seems to be in maintenance mode. It hasn't received new features in a decade (other than the port to .NET Core, if that counts). The Windows team has staffed it with a skeleton crew (a manager and 2 devs last I checked). They don't have bandwidth to review most community PRs, and even the .NET team doesn't get responses to issues: https://github.com/dotnet/wpf/issues/3811

idk, I hope I'm wrong but they have been promising improvements for a while and I'll believe it when I see it.

[phillipcarter]

Ooof, yeah, I should have looked at the commit history. It does look like a skeleton crew and all the knowledge of WPF is in another team now. What a shame. At least WPF is stable for what it is though.

[temac]

> 64-bit solves so many perf and user-perceived reliability issues

I love how in tech everything is always evil one day and the next one nearly the panacea. Now I understand the timing component is actually not to get rid of entirely, in the sense that maybe a 64-bit VS would have been a bad idea the year AMD released x64, but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance.

I suspect the cold reality was that the code base was not ready and the migration just took some time :)

[phillipcarter]

>but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance.

Yeah, this was from a series of articles that were a great example of managing to be right about all kinds of things but still be wrong in the end.

Specifically, the articles laid the blame for things like memory usage (which when high enough, causes a foreground GC in the devenv.exe process that freezes your UI), on language services that get all too happy to allocate tons of memory. If you make this 64-bit, pointers double in size and you could observe even more memory usage. 64-bit is also objectively slower than 32-bit in terms of CPU time to execute stuff. The solution it suggested was for memory-intensive components to move out of process, which is actually what many of them did in VS 2017 and VS 2019.

But the problem with this article is that it was entirely speculation. It did not account for several things:

* A 64-bit devenv.exe process gives the GC more "room to work with" and do more background GCs rather than foreground GCs, which will pause the UI far less

* Marshaling data between processes still requires use of the UI thread in VS in various scenarios, due to a wildly complicated threading model that people mess up all the time

* You really don't know what the impact of something is going to be until you actually do it

* If you commit to something ambitious like going 64-bit only, engineers can meet the challenge and produce something very good

My personal belief is that 64-bit could have been reasonably accomplished many years ago, and it would have been the right call to do it then. But I won't be looking a gift horse in the mouth. The codebase I contribute to is so much more pleasant to work in with VS 2022.