#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 simonpj): I have a large collection of eta-related tickets. See "Arity" in [wiki:Status/SLPJ-Tickets]. This one is awkward. If we have {{{ f True = \x -> .. f False = \y -> .. }}} and `f` is usually called applied to two arguments, it's really much better to eta-expand. But if we have `map (f v) xs` it probably isn't better to eta-expand. Generally, GHC will eta expand if the only duplication is pattern matching; but as you point out that is not always right. Currently there is no notion of how ''much'' pattern matching is duplicated, and that might not be hard to add. Another avenue would be to give programmers a way to control the behaviour, along the lines of the existing `oneShot` [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- prim-0.4.0.0/GHC-Magic.html docs]. I wish I knew a really good way to deal with this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11029#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler