#13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I went wild on the debug logging when compiling bad.hs, with GHC HEAD and the patch from comment:24 in place. One thing that sticks out is that at some point, total Core size goes from about 7,700 to 685,000: {{{ Result size of Simplifier iteration=4 = {terms: 7,759, types: 9,295, coercions: 847, joins: 9/84} Result size of Simplifier = {terms: 7,759, types: 9,295, coercions: 847, joins: 9/84} !!! Simplifier [Main]: finished in 1123.65 milliseconds, allocated 1251.533 megabytes *** SpecConstr [Main]: Result size of SpecConstr = {terms: 685,052, types: 613,224, coercions: 22,309, joins: 1,571/11,551} }}} Subsequent simplifier runs bring this down to 70,000 eventually, and then it jumps up to 96,000 again at the CorePrep stage, but it never goes back down to anywhere near those 7,000. If, however we enable the `{-#NOINLINE#-}` pragma on `mhelper`, then that same SpecConstr step maintains Core size exactly (suggesting that it doesn't do anything at all). `mhelper` is ` :: MonadIO m => ...`; if we inline it, then `m` can be specialized to `Handler`, which is a synonym for `ReaderT () IO`. I don't know why this particular specialization blows up right there and then, but that's what I've figured so far. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13253#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler