[GHC] #7258: Compiling DynFlags is jolly slow

[GHC]

#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