If they're Web projects and you have node_modules (or a similar huge number of files) in a subfolder, you may need to exclude them in your project configuration. I've found dotnet core builds to be very fast, unless the build is accidently scanning a few hundred thousand files it doesn't need to. Example at very top: https://github.com/caseymarquis/QApp/blob/master/App/App.csp...

I tend to take the a .gitignore for C# and merge the Node baseline together, add in test* and .* roughly speaking [1]

For that matter, anything using node/npm on anything but SSD/NVME is VERY slow (HDD, even enterprise drives)... local builds for me are in a couple seconds for a large complex project, on the servers it's minutes. So, YMMV.

The API layer I'm working against is .Net core, local build is under 3 seconds, building/deploying 12 seconds on my desktop (kills existing container, builds in one container, deploys to another and starts) docker for Mac, probably faster on linux... NVME drive on i7-4790K, 32GB RAM.

[1] https://gist.github.com/tracker1/8cd6309ecc3e480616f79e83712...

I don’t think it’s the compiler actually. I’m more inclined to blame the project system. In fact visual studios does some hacks just to get around it in some perofrmace sensitive things.

Indeed. It's actually pretty easy to write a custom msbuild logger to instrument (and subsequently chart) all the steps and you discover most of the wall clock time on big solutions with large numbers of projects is not actually compile time. csc itself is fairly competitive with javac. But by Christ, msbuild and nuget restore (which needs to run masses of msbuild machinery these days) are slow.

It's definitely the project system. I once worked on a solution containing ~150 projects. I consolidated all the code down to about 15 projects and the build time of the solution dropped by about 5x. I've been working in Java lately and frankly, I see little difference in compilation speeds between the two.

Rider uses the same project system, so I haven't had a chance to observe any alternative.