#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