#7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): `tryToInline` is in in `CmmSink` which we already know is working too hard. There may well be algorithmic improvements that could be done `CmmSink`. But, in addition, I would still like to understand why the STG-to-Cmm ratio climbs so sharply. If we have giant Cmm then any Cmm pass is going to take a long time. Fixing the non-linearity would be good, I agree; but generating less Cmm would also be big. Why is it so big? My guess: we are generating very deeply-nested closures that have a lot of free variables. E.g. {{{ let x = let a5 = blah q = ...K a1 a2 a3 a4 a5 ... in ... }}} Here the closure for `q` has 5 free variables (a1-a5); while that for `x` has four (a1-a4). So the code for `x` will slurp lots of variables out of x's closure only to store them again in q's. And if that is nested we'll get `O(n**2)` code size. But I'm speculating. Facts would be good. Let's measure STG size with and without counting the free vars of each closure (which are stored in the STG tree) and see. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7258#comment:84 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler