#13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The first weird thing to notice about this problem is that 45d9a15c4b85a2ed89579106bdafd84accf2cb39 is all about LHSes of `RULES`, but there ''aren't any'' rules in the test module. So something seems to have gone wrong with one of the "knock on" changes. Compiling before and after with `-v3` indicates that the simplifier iteration immediately after float out takes ''much'' longer, and produces somewhat more coercions. That iteration takes many times longer than any other. Most of the coercions, before and after, go away after that iteration, stabilizing quickly at 19. Surprisingly, `-dverbose-core2core` looks exactly the same before and after that commit, suggesting something went funny with the size calculations, although I can't see how. In HEAD, the number of coercions never goes up above 19. Furthermore, the time problem has ''moved''. Now, the long iteration is the very first one after desugaring! Ugh. I haven't yet tried to find where the time shift took place. But the fact that there ''was'' one makes me suspect that the new implementation could have accidentally strictified something it shouldn't have. I don't understand what's going on well enough to know what. Perhaps the fact that a couple pure functions have turned monadic? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13379#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler