  > The goal is to transparently replace dedicated developer workstation

Isn't there a less convoluted way of making the best engineers leave? I am half serious here. If you want your software to run slow, IT could equally well install corporate security software on developer laptops. Oops, I did it again. Oh well, in all seriousness, I have never seen any performance problem being solved by running it on Azure's virtualization. I am afraid you are replacing the hardware layer by a software layer with ungodly complexity, which you are sure of will be functionally incomplete.

Are you sure they don't have to fix the build pipeline first? Tens of thousands of vCPUs for a single compilation run, or to accommodate 100 developers who try to compile their own changes?

▲ jjmarr 7 hours ago | parent [-]

> I have never seen any performance problem being solved by running it on Azure's virtualization

Sorry, I wasn't clear. I am not virtualizing the workspace. I'm using `recc` which is like `distcc` or `ccache` in that it wraps the compiler job. Every developer keeps their workstation. It just routes the actual `clang` or `gcc` calls to a Kubernetes cluster which provides distributed build and cache.

> Isn't there a less convoluted way of making the best engineers leave?

We have 7000+ compiler jobs in a clean build because it is a big codebase. People are waiting hours for CI.

I'm sure that drives attrition and bringing that down to minutes will help retain talent.

> Tens of thousands of vCPUs for a single compilation run, or to accommodate 100 developers who try to compile their own changes?

Because it uses remote execution, it will ideally do both. My belief is that an individual developer launching 6000 compiler jobs because they changed a header will smooth out over 300 developers that generally do incremental builds. Likewise, this'll eliminate redundant recompilation when git pulling since this also serves as a cache.

▲

js4ever 6 hours ago | parent [-]

This makes absolutely no sense to me. Are you really recompiling 6000 things each time a dev in the company needs to add a line somewhere in the codebase? Have you thought about splitting that giant thing in smaller chunks?

	▲	jjmarr 6 hours ago \| parent [-]
		> Are you really recompiling 6000 things each time a dev in the company needs to add a line somewhere in the codebase? It happens when someone modifies a widely included header file. Which there are a lot of thanks to our use of templates. And this is just our small team of 300 people. > Have you thought about splitting that giant thing in smaller chunks? Yes. We've tried but it's not scaling. Unfortunately, we've banned tactics like pImpl and dynamic linking that would split a codebase unless they're profiled not to be on a hot path. Speed is important because I'm writing tests for a semiconductor fab and test time is more expensive than any other kind of factory on Earth. I tried stuff like precompiled headers but the fact only one can be used per compilation job meant it didn't scale to our codebase.