#11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): @nomeata: I confirm {{{-O1}}} has exactly the same behaviour. As for fixes, my first thought is that eta-expansion is valuable even if you are duplicating more than patterns, and sometimes duplicating patterns is too much. My hypothetical solution would be: * Make each function have multiple versions at different arities, so you'd generate core for {{{test1/1}}} and {{{test1/2}}}. (The functions might refer to each other, or not be generated if it didn't seem valuable, to keep the size down.) * Have the call site select between {{{test1/1}}} and {{{test1/2}}} based on the number of arguments available. * After that, you might want to change the desugarer, so that the two functions above produce the same Core. Pattern matching on the first argument could happen after the first argument is supplied, before the second argument. It would be nice if the 2 argument version still went 3x faster when used partially applied. Trying to figure out the arity of a function at it's definition site seems difficult, and can never be optimal for all uses. For context, I got lead down this path starting at view patterns, which have similar considerations but with arbitrarily expensive "patterns", which GHC never duplicates: http://neilmitchell.blogspot.co.uk/2015/10 /viewpatterns-and-lambda-expansion.html. In Shake someone submitted a patch to refactor and move a lambda to the left of an {{{=}}}, which somewhat surprisingly can be much slower. Adding a {{{oneShot}}} equivalent would be very useful, to make such optimisations explicit and robust. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11029#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler