[GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth

[GHC]

#10980: Deriving Read instance from datatype with N fields leads to N^2 code size
growth
-------------------------------------+-------------------------------------
        Reporter:  slyfox            |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.10.2
      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 nomeata):

 (In reply to comment:12) Is this a specific `+`, or just the overloaded
 method from `Num`? I guess the latter, as a strict `+` would yield quite
 different code.

 So you are proposing to add a transformation to STG (or Core) that
 replaces
 {{{
 let t1 = let t2 = e1
          in e2
 in e3
 }}}
 with
 {{{
 let t2 = e1
     t1 = e2
 in e3
 }}}

 Can we give an easy criterion when this transformation is beneficial?

 The problem is that this will increase allocation in the case when `t1` is
 not called, as it is more space efficient to pack the union of the free
 variables of `e1` and `e2` into one closure, instead of having one for the
 free variables of `e1` and one for those of `e2`.

 We could say “Do this transformation if the free variables of e2 and e1”
 are disjoint. Then we’d allocate two extra words (one for the info table
 of `t2`, and one pointer to that in the closure for `t1`), but have some
 nice gains if `t1` is indeed called.

 But this rule would not fire in this case, because the `Num a` dictionary
 is also a free variable, which would now have to be copied into both
 closures!

 I guess one could try and see whether real-world programs benefit from
 this transformation, and how many shared free variables between `e1` and
 `e2` are ok.

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