[GHC] #10528: compile time performance regression with OverloadedStrings and Text

[GHC]

#10528: compile time performance regression with OverloadedStrings and Text
-------------------------------------+-------------------------------------
        Reporter:  jakewheat         |                   Owner:
            Type:  bug               |                  Status:  merge
        Priority:  high              |               Milestone:  7.10.3
       Component:  Compiler          |                 Version:  7.10.2-rc2
      Resolution:                    |                Keywords:
Operating System:  Linux             |            Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by afarmer):

 As an example of what is happening, we are seeing rules like this:

 {{{
 repH :: [a] -> [a] -> [a]

 {-# RULES "repH ++" [~] forall xs ys. repH (xs ++ ys) = repH xs . repH ys
 #-}
 }}}

 get to HERMIT as:

 {{{
 "repH ++" forall xs ys. repH (xs ++ ys) = let f = repH xs
                                               g = repH ys
                                           in \ z -> f (g z)
 }}}

 In this case it is just an unfolding of composition, but some rules get
 rather gross on the RHS. The extra junk makes equational reasoning with
 these rules very fiddly and sort of breaks the correspondence with the
 source-level code.

 Some possible solutions that occur to me:

 1. If we could get access to the rules before this inlining/rule
 application in the RHS occurs, then we wouldn't care what happens to them
 later. So just delaying things a bit.

 2. If we don't inline/apply rules in the RHS at all (as above).

 3. If we don't inline/apply rules in the RHS of rules marked with the
 NeverActive notation (rules intended for HERMIT use are generally
 NeverActive).

 4. We implement our own concrete syntax for HERMIT rules and stop abusing
 RULES pragmas. I realize this is probably the "best" solution, but it's
 also an API-breaker that I'm guessing would land in 7.12 at the earliest.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10528#comment:38>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler