[bonoetmalo]

You'll find a much different experience with OOM exceptions for developers working on large solutions, especially ones that contain a lot of test projects and small test assets. They've improved on it in 2017 but it's still pretty bad, OOM full crashes multiple times a day.

[zamalek]

We're at 25mloc, things can be sluggish but not broken.

[bonoetmalo]

I think it's less a LoC thing than it is a number of symbols/files thing. We have some 900k+ tests with an accompanying large number of test asset files. That means 900k public methods that test discovery has to process in realtime.

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.

[zamalek]

> on us to move away from the antipattern of solution monoliths

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.

[megaman22]

What are your loc? I've found that the language makes a huge difference. Visual Studio performs wildly differently on JS heavy projects, vs C# heavy projects, vs C++ projects.

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.