[GHC] #5642: Deriving Generic of a big type takes a long time and lots of space

[GHC]

#5642: Deriving Generic of a big type takes a long time and lots of space
-------------------------------------+-------------------------------------
        Reporter:  basvandijk        |                Owner:  bgamari
            Type:  bug               |               Status:  merge
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.3
      Resolution:                    |             Keywords:  deriving-
                                     |  perf, Generics
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:  T5642
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D2304
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by rrnewton):

 Small addendum.  If you split this up and compile the "from" and "to"
 methods separately, it is clear that most of the work is in the
 "from".  On the small-four constructor examples:

 Version 1:
  * 239 coercions with both to/from.
  * 200 coercions with just "from"
  *  39 coercions with just "to"

 Version 2:
  * 174 coercions with both to/from.
  * 132 with just from
  * 42 with just "to"

 And on the full-sized, 300-way sums, here are the realtime
 measurements on my personal machine:

 Version 1:
  * both:      639K coercions, 7.0s
  * from-only: 636.9K coercions, 5.7s
  * to-only:   2K coercions, 1.8s

 Version 2:
  * both:      9.9K coercions, 4.4s
  * from-only: 7.5K coercions, 3.6s
  * to-only:   2.4K coercions, 1.0s

 At least in the bigger case, it looks like there is a drop in realtime
 for both of the from/to methods, with the former being
 constructor-heavy, and the latter being deep-pattern-match-heavy.


 Slicing it another way, if we cut down the cases in the 300-way match
 for "from-only"/v1 -- leaving incomplete pattern matches -- the
 coercions/time drops as follows:

  * 300 cases -- 636.9K coercions, 5.7s
  * 150 cases -- 316K   coercions, 4.0s
  * 100 cases -- 212K   coercions, 2.5s
  *  50 cases -- 106K   coercions, 1.3s
  *  25 cases --  53K   coercions, 0.8s

 And "from-only"/v2:

  * 300 cases -- 7.5K coercions, 3.7s
  * 150 cases -- 5.8K coercions, 2.8s
  *  50 cases -- 4.8K coercions, 1.1s
  *  25 cases -- 4.5K coercions, 0.7s

 Ok, so nothing that unusual in this dimension.  As should be expected,
 the "factored" v2 gets a larger benefit over v1 the more cases the
 factored bit is amortized over.

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