[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):

 > read, read-appl and show "explode" while all the other examples,
 including getline-appl and getline, behave properly.

 Very good!

 {{{
 sink            CmmPipeline compiler/cmm/CmmPipeline.hs:(104,13)-(105,59)
 77.8   23.6
 SimplTopBinds   SimplCore   compiler/simplCore/SimplCore.hs:761:39-74
 9.6   30.0
 FloatOutwards   SimplCore   compiler/simplCore/SimplCore.hs:471:40-66
 3.0   10.4
 }}}

 What does `-dshow-passes` show about the program size?  I.e. are we
 getting very large Core?

 So `sink` in C-- seems very slow.  Nearly 4 bytes in 5 of all allocation
 is in tis pass alone. Is this a non-linear algorithmic effect.  e.g if you
 double the size of the input, does the `sink` time go up non-linearly
 while `simplTopBinds` goes up linearly?   That's my guess.

 (Related question: does `sink` show up a a big item when compiling
 "normal" programs?)

 Guessing: the "shape" of the C-- code makes `sink` behave very badly.  Can
 you characterise what that shape is, and where the algorithmic badness
 comes from?

 This is good... fixing these performance bumps will likely help ALL
 programs, even ones that don't hit the really bad spots.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7258#comment:57>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler