diff options
author | Alp Mestanogullari <alpmestan@gmail.com> | 2018-12-07 10:42:08 +0100 |
---|---|---|
committer | Alp Mestanogullari <alpmestan@gmail.com> | 2018-12-07 10:42:08 +0100 |
commit | eee1b61f85d949aa7c4bc496b5579cf759d1861e (patch) | |
tree | 28ac739c9b651904d88a3001262975c8df59ac18 /hadrian/src/Rules.hs | |
parent | fb669f51b3f2cae79511ac3d1c43939d951b1f69 (diff) | |
download | haskell-eee1b61f85d949aa7c4bc496b5579cf759d1861e.tar.gz |
hadrian: optimise Rules.Compile
Previously, as reported in #15938, resuming a build "in the middle",
e.g when building _build/stage1/libraries/base/, hadrian would take up
to a whole minute to get started doing actual work, building code.
This was mostly due to a big enumeration that we do in Rules.hs, to
generate all the possible patterns for object files for 1) all ways, 2)
all packages and 3) all stages. Since rule enumeration is always
performed, whatever the target, we were always paying this cost, which
seemed to grow bigger the farther in the build we stopped and were
resuming from.
Instead, this patch borrows the approach that we took for Rules.Library
in https://github.com/snowleopard/hadrian/pull/571, which exposes all the
relevant object files under as few catch-all rules as possible (8 here),
and parses all the information we need out of the object's path.
The concrete effect of this patch that I have observed is to reduce the
45-60 seconds pause to <5 seconds. Along with the Shake performance
improvements that Neil mentions in #15938, most of the pause should
effectively disappear.
Reviewers: snowleopard, bgamari, goldfire
Reviewed By: snowleopard
Subscribers: rwbarton, carter
GHC Trac Issues: #15938
Differential Revision: https://phabricator.haskell.org/D5412
Diffstat (limited to 'hadrian/src/Rules.hs')
-rw-r--r-- | hadrian/src/Rules.hs | 19 |
1 files changed, 7 insertions, 12 deletions
diff --git a/hadrian/src/Rules.hs b/hadrian/src/Rules.hs index 852bd5dbc8..0e55087b7d 100644 --- a/hadrian/src/Rules.hs +++ b/hadrian/src/Rules.hs @@ -94,18 +94,7 @@ packageRules = do let readPackageDb = [(packageDb, 1)] writePackageDb = [(packageDb, maxConcurrentReaders)] - let contexts = liftM3 Context allStages knownPackages allWays - vanillaContexts = liftM2 vanillaContext allStages knownPackages - - -- TODO: we might want to look into converting more and more - -- rules to the style introduced in Rules.Library in - -- https://github.com/snowleopard/hadrian/pull/571, - -- where "catch-all" rules are used to "catch" the need - -- for library files, and we then use parsec parsers to - -- extract all sorts of information needed to build them, like - -- the package, the stage, the way, etc. - - forM_ contexts (Rules.Compile.compilePackage readPackageDb) + Rules.Compile.compilePackage readPackageDb Rules.Program.buildProgram readPackageDb @@ -116,6 +105,12 @@ packageRules = do -- being forced. Rules.Register.registerPackage writePackageDb (Context stage dummyPackage vanilla) + -- TODO: Can we get rid of this enumeration of contexts? Since we iterate + -- over it to generate all 4 types of rules below, all the time, we + -- might want to see whether the parse-and-extract approach of + -- Rules.Compile and Rules.Library could save us some time there. + let vanillaContexts = liftM2 vanillaContext allStages knownPackages + forM_ vanillaContexts $ mconcat [ Rules.Register.configurePackage , Rules.Dependencies.buildPackageDependencies readPackageDb |