Richard, In an effort to figure out why programs with lots of type families have become so much slower over the last few GHC releases, I've been looking at GHC Trac #12545 [1], which provides a very self-contained test case that became considerably slower to compile from GHC 7.10 to 8.0. Thanks to this test case, I found one of the sources of the slowdown: a single, very small commit of yours [2]. What's baffling, though, is that I can't figure out why that commit makes compilation so much slower. I tried making profiled builds of GHC before and after that commit and attaching SCCs to the new code, but to my surprise, their contribution to the overall compilation time was negligible. So I'm out of ideas on what might be causing this. The only hint I have is the output of -ddump-simpl-stats/-dshow-passes. Before that commit, there's a point where the terms, types, and coercions go up: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 20,769, types: 1,157,897, coercions: 3,635,961} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 44,081, types: 2,451,155, coercions: 9,802,016} But after that commit, the terms and types jump up considerably higher! *** Simplifier: Result size of Simplifier = {terms: 16,429, types: 864,761, coercions: 2,184,448} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 87,357, types: 4,366,893, coercions: 10,008,352} Here are the relevant bits from -ddump-simpl-stats. Before that commit: 150 PreInlineUnconditionally 40 PostInlineUnconditionally 220 UnfoldingDone 110 RuleFired 380 BetaReduction After that commit: 306 PreInlineUnconditionally 160 PostInlineUnconditionally 360 UnfoldingDone 308 RuleFired 1238 BetaReduction Does you know what might be going on here? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12545 [2] https://ghc.haskell.org/trac/ghc/changeset/1722fa106e10e63160bb2322e2ccb830f...