#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): I cherry-picked bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841 onto the 7.10.2 release branch and built it to test HERMIT. It does fix the problem we were having with the LHS of rules being altered by the simplifier, which is good. However, the inlining/rule application still appears to be happening in the RHS of the rules, which wasn't expected. Looking at the patch, I see the simplifier environment for the RHS still allows inlining/rule application. Can we change the simplification of the RHS to also not inline/apply rules? (I'm happy to submit a patch that does this.) I assume doing so in the RHS saves redundant simplifier work, but (even outside HERMIT's use) the unexpected RHSs make it difficult to glue together rules into rewrite systems. For instance, given the following dummy rule set: {{{#!hs "foo" forall x. foo x = bar (baz x) "baz-quux" forall y. baz (quux y) = norf y }}} If this expression appeared: {{{#!hs foo (quux z) }}} I would expect it to be rewritten to: {{{#!hs bar (baz (quux z)) }}} then: {{{#!hs bar (norf z) }}} But, if `baz` is inlined in the RHS of rule "foo", then rule "baz-quux" may never get to fire on the result of "foo" applications. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10528#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler