[GHC] #11196: TypeInType performance regressions

[GHC]

#11196: TypeInType performance regressions
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by goldfire):

 * priority:  normal => highest
 * version:  7.10.2 => 7.11
 * milestone:   => 8.0.1


Old description:

> This ticket is to track the handful of performance regressions seen with
> the addition of `TypeInType`. It is quite possibly a good idea to break
> these out into separate tickets, but until we investigate, they're all
> bundled here.
>
> The regressions are:
>   * T3064, bytes allocated up by 14.9%
>
> (will update description)

New description:

 This ticket is to track the handful of performance regressions seen with
 the addition of `TypeInType`. It is quite possibly a good idea to break
 these out into separate tickets, but until we investigate, they're all
 bundled here.

 The regressions are:
   * T3064, bytes allocated up by 14.9%
   * T5030, up by 61.8%
   * T5837, up by 13%
   * T5321Fun, up by 11%
   * T5631, up by 39%
   * T9872d, '''down''' by 91.8%  (see below)
   * T9872a, up by 33.6%
   * T9872c, up by 59.4%
   * T9872b, up by 49.4%
   * T9675, up by 29.7%, and peak megabytes allocated up by 28.4%
   * haddock.base, up by 12.4%
   * haddock.Cabal, up by 9.5%

 I did add an optimization around type family reduction (the function
 `zonk_eq_types` in !TcCanonical) that could cause such a drastic
 reduction.

--

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