#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