[kllrnohj]

> It is not always possible to just throw more hardware at the problem of compilation. For instance, one may be using a build pipeline that requires specific steps to be followed as part of gating tasks. The time it takes to compile code over and over again for unit testing, behavioral testing, acceptance testing, integration testing, etc., each impacts delivery time and handoff.

All of that is solved by throwing more hardware at it.

Alternatively if compile time is not the slow part of that pipeline, then you're prematurely optimizing the wrong thing anyway.

> Earlier in my career, I worked with a code base that was approximately 10 million lines of code in size. Compiling this code base would take approximately 7 hours on the best hardware we could buy. The C++ developers were adamant about ensuring that their headers were "complete" as they called it. With a few changes, such as forward declarations, abstract interfaces, and encapsulation, my team was able to reduce that compile time to less than 35 minutes.

In other words you only optimized the critical 3% of the codebase rather than prematurely optimizing everything with pImpl abstractions?

[nanolith]

> Alternatively if compile time is not the slow part of that pipeline, then you're prematurely optimizing the wrong thing anyway.

Developer productivity does not matter in your world?

> In other words you only optimized the critical 3% of the codebase rather than prematurely optimizing everything with pImpl abstractions?

Yes, because nowhere in this thread have I advocated prematurely optimizing everything with pImpl abstractions. Those are words you have put in my mouth. pImpl abstraction is a single tool that can be used to improve compile-time performance. Not all the time, but in a fraction of the 3% of the time where it is appropriate.