[GHC] #9233: Compiler performance regression

[GHC]

#9233: Compiler performance regression
-------------------------------------+-------------------------------------
              Reporter:  augustss    |             Owner:
                  Type:  bug         |            Status:  new
              Priority:  low         |         Milestone:
             Component:  Compiler    |           Version:  7.8.2
            Resolution:              |          Keywords:
Differential Revisions:              |  Operating System:  Windows
          Architecture:              |   Type of failure:  None/Unknown
  Unknown/Multiple                   |         Test Case:
            Difficulty:  Unknown     |          Blocking:
            Blocked By:              |
       Related Tickets:              |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 I'm looking into this now.

 I don't really like the optimization in `mkNthCo`. It's almost certainly
 correct and harmless, but it's quite incompatible with my work on a branch
 of GHC that has changed coercions quite a bit. (The branch is integrating
 dependent types into GHC.) And, the problem shouldn't be there in the
 first place, so that optimization is just masking something deeper.

 In looking at the minimized test case (thanks!) I'm flummoxed by the
 dependency on the magical number "10" for the `Options` type. Does that
 have to do with inliner thresholds? This is an area I'm not familiar with.

 But, I'm almost positive that the 10-field cutoff is unrelated to the
 underlying problem of coercion blowup and quartic (!) slowdown. I'm not
 convinced that the coercion blowup, itself, is so terrible, but quartic
 behavior certainly is.

 Will post if I have any more news.

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