#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