#15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I'm looking into Andrey's suggestion (which I have been meaning to do for a while, ever since we implemented the "new" `Rules.Library` module). I did some profiling myself and the picture becomes even clearer if we hide shake from it: {{{ COST CENTRE MODULE SRC %time %alloc compilePackage Rules.Compile src/Rules/Compile.hs:(13,1)-(36,77) 49.2 78.4 split Data.List.Extra src/Data/List/Extra.hs:(569,1)-(571,48) 41.7 8.6 modifyVar Control.Concurrent.Extra src/Control/Concurrent/Extra.hs:191:1-36 2.3 1.1 buildPackageDependencies Rules.Dependencies src/Rules/Dependencies.hs:(15,1)-(35,52) 1.5 2.9 generatePackageCode Rules.Generate src/Rules/Generate.hs:(102,1)-(150,49) 0.5 1.6 configurePackage Rules.Register src/Rules/Register.hs:(24,1)-(27,38) 0.4 1.5 }}} While Shake itself might benefit from some optimisations for those paths manipulations that are involved here, clearly our number one problem is the enumeration of contexts for `compilePackage` that we do in `Rules.hs`, as you pointed out @snowleopard. I'm going to migrate `Rules.Compile` over to the enumeration-less, parsing-based style the best I can and report back. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15938#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler