[GHC] #11029: Performance loss due to eta expansion

[GHC]

#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