It's not the tooling I dislike it's the performance. No matter what I throw at it I still get the same experience. It feels like 95% of everything it does is blocking the UI.
Improving perf in VS is hard without massive rewrites. The fundamental problem is that this is originally a COM app (as in, heavily using COM to componentize itself) designed back in mid-90s. Consequently, you get all the wonders of things such as STA apartments, and code that insists running thereon.
As it gets rewritten, new managed bits don't care about all that stuff. But so long as there's one bit of legacy code anywhere in the particular flow that needs to run on STA (usually it's UI thread), you get this whole "you have 20 cores and 60 logical threads, but all those threads need to sync on STA, so everything is serialized and slow" thing.
Even for the new code, the problem is that all those old COM APIs that it needs to interact with (not just for VS itself, but also for the sake of backwards compatibility with third party extensions) are usually synchronous. So if you want background processing, you need to spawn a thread - but, of course, threads aren't free, either.
I have the same experience, on Visual Studio for Mac. I was debugging some C# code with an infinite loop the other day, and it locked up the debugger too! Every time. No way to pause and step through the program, so I had to rely on the OS crash log to figure out what was going wrong.
It's not the tooling I dislike it's the performance. No matter what I throw at it I still get the same experience. It feels like 95% of everything it does is blocking the UI.