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

 Replying to [comment:7 simonpj]:
 > Great work.  There is definitely a space leak here and it should not be
 to hard to find.  Some ideas
 >
 > * In `CoreLint.lintSingleBinding` you'll find a series of tests.  If you
 comment then out one by one, you'll find when the space leak comes back.
 That test must be forcing the offending bit of `IdInfo`.

 I commented out `lintIdUnfolding` and then the leak came back with
 `-dcore-lint` enabled.

 > * Does the leak happen when you use `-dshow-passes`?  That shows the
 size of eac intermediate,
 and `exprSize` is deliberately strict (see `CoreStats.bndrSize`).

 I've been using `-v`, which I think shows the same information, and it
 doesn't eliminate the leak.

 >   You could try making `CoreSeq.megaSeqidInfo` actually force the
 unfolding info (currently commented out) and see if that helps.  (I'm not
 sure WHY it is commented out, incidentally.)

 Instead I defined a new version of `seqUnfolding`, based on
 `lintIdUnfolding`, and added it to `megaSeqIdInfo`:
 {{{#!hs
 miniSeqUnfolding :: Unfolding -> ()
 miniSeqUnfolding (CoreUnfolding { uf_tmpl = e, uf_src = src })
   | isStableSource src
   = seqExpr e
 miniSeqUnfolding (DFunUnfolding { df_con = con, df_bndrs = bndrs
                                             , df_args = args })
   = seqExprs args
 miniSeqUnfolding _ = ()
 }}}
 This was enough to make the leak go away, even without using `-dcore-
 lint`. Both the `CoreUnfolding` and `DFunUnfolding` cases are needed to
 make the leak go away; or perhaps there are two leaks. (Without the
 `isStableSource` guard, the runtime exploded.)

 So there are thunks in the expressions inside unfoldings which, I believe,
 point to old versions of the Core program. I'm going to continue
 invesigating but I'm out of time for today.

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