Losing (parallel) sleep over module dependencies
Hi all, I get worried quite often about the interaction of two facts 1. Adding a new dependency to a module is easy. 2. Adding a new dependency changes the build graph and potentially reduces the amount of parallelism which the build is capable of. Has anyone thought of any strategies to analyse the dependency graph of GHC so that a linter can be created to warn against any changes which create dependencies which affect the parallelism? hs-boot files make this issue even worse I think but I'm not sure of the precise recompilation semantics. It would be quite straight forward to index ghc as it is being built to create a dependency graph (at the identifier) level but it's unclear to me whether it is possible to do anything productive with this information. Cheers, Matt
Matthew Pickering
Hi all,
I get worried quite often about the interaction of two facts
1. Adding a new dependency to a module is easy. 2. Adding a new dependency changes the build graph and potentially reduces the amount of parallelism which the build is capable of.
Has anyone thought of any strategies to analyse the dependency graph of GHC so that a linter can be created to warn against any changes which create dependencies which affect the parallelism?
hs-boot files make this issue even worse I think but I'm not sure of the precise recompilation semantics.
It would be quite straight forward to index ghc as it is being built to create a dependency graph (at the identifier) level but it's unclear to me whether it is possible to do anything productive with this information.
In principle we could just produce a Hadrian profile as a CI product. From this you could compute the mean available parallelism over the course of the build and record this as a performance metric for, e.g., gipeda. Cheers, - Ben
participants (2)
-
Ben Gamari -
Matthew Pickering