#7511: Room for GHC runtime improvement >~5%, inlining related ------------------------------------+--------------------------------------- Reporter: danielv | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Comment(by nfrisby): Just FYI, I've recently seen one example where more inlining caused an increase in allocation. Here's an abstraction: {{{ f a b = let-no-escape j = ... in ... j ... g x y = ... case f (...) (...) of ... }}} f got inlined and the j binding got floated out a bit. Thus j was no longer LNE, since the result of its call was scrutinized. This happened in puzzle; the StateType's == and /= methods were f and g, respectively. I had accidentally awarded a huge result discount to ==. Yell if you'd like more details. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7511#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler