Observation on Hadrian's relative performance re current buildsystem

[Herbert Valerio Riedel]

Hi Malcolm,

On 2017-11-18 at 11:09:28 +0000, Malcolm Wallace wrote:

[...]

> But surely the timing for a full build from scratch is not the most
> important thing to compare?  In my work environment, full builds are
> extremely rare; the common case is an incremental build after pulling
> changes from upstream.  Is this something you can measure?

If Hadrian is more exact about the dependency tracking, I'd expect
something close to a full rebuild when I `git pull` from GHC HEAD, since
the Git commit and the snapshot versioning we infer from that,
pervasively transcends most most artifacts of GHC, and in general you
should boot & configure everytime you `git pull` unless you're sure it
won't matter.

You'd have to suppress/mask this logic if you want to avoid full
rebuilds.

Also I'm not sure how Hadrian tracks itself as a dependency (NB: The GNU
Make system doesn't); When I used Shake myself, I remember that
meta-depending on the rules per se wasn't a trivial thing to do; and the
simplest way was to introduce very coarse (either manual or by hashing)
global versioning over all rules, which would invalidate the full
build. But it's been some time since I did that, so I may be wrong here.

However, what I think would be a more relevant benchmark matching the
usual GHC developer workflow, would be to see how well Hadrian manages
to minimize the work needed to rebuild GHC after editing a source file
in GHC's source-tree without changing the Git commit. As that's what
matters most to me when I'm actively working on a GHC patch.

I'll try to measure/compare this with the next GHC patch I hack on.