Second-hand knowledge here- I heard that VS 2010 was delayed because it would crash out of memory under many common scenarios- like load WinForms designer, TFS and one other module and boom. So every team had to go on a serious diet.
The only reason you haven't gotten an out of memory is that the VS team has been fighting like mad to support common scenarios in the 32-bit address space.
It's partially on us to move away from the antipattern of solution monoliths, and to nugetize crap that doesn't need to actually be in the solution. But it's also on Microsoft to lazily load projects that aren't being used.
We started that about 6mo ago. It's worth it but good luck. Spend a lot of time understanding your codebase. Spend more time understanding DDD (there are great courses on Pluralsight). You're going to learn a lot and it's going to be both rewarding and hell.
> But it's also on Microsoft to lazily load projects that aren't being used.
They have that fast solution load thing in 2017, I'm not entirely sure what it does but maybe it's worth a shot.
JS code files slow everything down so badly in VS my preferred method is rip it all out of the VS solutions and do front-end work in WebStorm.
> 64-bit
I've never experienced an out-of-memory with VS, so that whole argument is moot.