Measure compile-time costs

Measure the incremental compile time impact of a new header we added. Build a clean Release object with -j8 for the main executable before and after adding that header, record wall-clock time and per-translation-unit times, and produce a short table showing which .cpp files increased compile time by more than 5%. Summarize whether the header caused more template instantiations or included heavy system headers.

Before I present compile-time changes to the team, make it easy to act on: highlight the top five translation units with the largest regression, show which included headers they pull in and how many symbols or template instantiations that introduces, and flag quick fixes like forward declarations, pimpl, or moving headers to implementation files with an estimated time to fix.

After merging the refactor branch, CI compile time jumped 20% but the diff touches only utilities and a common header. I suspect increased template instantiations or an accidental include chain. I can't tell which TU exploded or whether the toolchain changed. What's the quickest way to localize the compile-time regression and prove whether it's caused by the header change or a CI toolchain difference?

Over many sprints we accumulate headers that drag compile times up and engineers tolerate long rebuilds. That kills willingness to run local builds and hurts review quality. Which three programming and repo habits should we change—include patterns, CI checks, or code-review signals—so compile times stay acceptable and regressions get caught immediately?