[GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2

[GHC]

#13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC
8.2
-------------------------------------+-------------------------------------
        Reporter:  hvr               |                Owner:  rwbarton
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
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 rwbarton):

 There was actually a third required change which I had guessed at earlier,
 namely changing
 {{{#!hs
 simplExprF1 env (Case scrut bndr _ alts) cont
   = simplExprF env scrut (Select { sc_dup = NoDup, sc_bndr = bndr
 }}}
 to
 {{{#!hs
 simplExprF1 env (Case scrut bndr ty alts) cont
   = seqType ty `seq`
     simplExprF env scrut (Select { sc_dup = NoDup, sc_bndr = bndr
 }}}

 Alternatively, one can insert a `seqType` into `reallyRebuildCase`:
 {{{#!diff
 @@ -2222,7 +2223,7 @@ reallyRebuildCase env scrut case_bndr alts cont

          ; dflags <- getDynFlags
          ; let alts_ty' = contResultType dup_cont
 -        ; case_expr <- seqType alts_ty' `seq` mkCase dflags scrut'
 case_bndr' alts_ty' alts'
 +        ; case_expr <- mkCase dflags scrut' case_bndr' alts_ty' alts'
 }}}

 I don't understand specifically why these changes make any difference,
 especially the first one, where we were throwing away the `ty` field
 anyways. It must share structure with some other part of the program, but
 I'm not sure what.

 Replying to [comment:14 simonpj]:
 > PS: you may then be able to get rid of the call to `coreBindsSize` in
 `SimplCore`.  If so, that would be good: faster compilation!  Worth
 trying... it might I suppose show up another leak currently patched by
 `coreBindsSize`.

 Yes, I'll try that next as I have a good setup for finding leaks now.

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