#14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): Ok, I've just re-visited this issue and I've got one additional question. GHC.Base has definition of `(.)` like the following : {{{ (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} }}} @simonpj You've told that making own definition of (.) with one of its arguments strict, obviously affects the performance (makes the custom (.) implementation 40x faster in some use cases). I still consider it to be GHC bug even if we can justify it by some internal compiler design. If GHC is told to inline the `(.)` definition, why inlining such code into strict code doesn't make GHC automatically discover that every parameter was already strict there? Why inlining such definition makes strict code run slow? I'm looking at it from user perspective. For me telling users to have two definitions of (.) - one strict and one lazy and using strict one in strict code and lazy one in lazy code makes Haskell so hard to understand and so hard to use. Thus I believe we should consider this bug and should expect from GHC to automatically optimize usages of (.) in strict code. If I understand correctly, what happens here is that arguments to (.) are boxed (because (.) was defined as lazy) and are unboxed as soon as passed to `f` and `g`, because they were defined as strict. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14001#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler