hadrian: Ticky flavour builds too much
Whenever I take Ticky measurements, I do so in Flavour perf+ticky_ghc
and then stare with dread at all the redundant compilation. For example
| Run Ghc CompileHs Stage1: compiler/GHC/Core/Type.hs => _ticky/stage1/compiler/build/GHC/Core/Type.p_o
| Run Ghc CompileHs Stage1: compiler/GHC/Core/Type.hs => _ticky/stage1/compiler/build/GHC/Core/Type.o
Why does it build every file twice? And when I look into the build output, I see
_ticky/stage1/compiler/build/compiler/GHC/Core/Type.debug.dump-stg-final
_ticky/stage1/compiler/build/compiler/GHC/Core/Type.debug_dyn.dump-stg-final
_ticky/stage1/compiler/build/compiler/GHC/Core/Type.debug_p.dump-stg-final
And I always wonder in which of the three files I should look up the binder names I see in the Ticky report. (The answer is _ticky/stage1/compiler/build/compiler/GHC/Core/Type.debug_dyn.dump-stg-final, at least on my last try.)
It also suggests that we run every file through the backend thrice! What a waste of time.
Now I grant you that this might be due to the particular combination of flavours and things might be better with e.g. default+ticky_ghc
or validate+ticky_ghc
(haven't tried). But can't we do better?
I'm not acquainted enough with all the different build configurations. But do we need the _p
files? I think these are for profile builds, but Ticky isn't the usual kind of profiling, so perhaps it should turn those off. And since we also don't seem to need the static, non _dyn
files, it suggests that we could get by with just -dynamic
. Is that assessment right? I'm willing to try and report.