#13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The patch in #8472 allows floating out unboxed string literals to top level in (at least) three places: 1. In the "Floats" section in SimplEnv we float a let out of a let. If the body of the let is a lambda then we can increase the arity of the original binding, which is a good thing. This is the optimization that was allowed in the example of #8472 by letting the unboxed string literal float to the top level. 2. In `prepareRhs` in Simplify we can float, for example, an argument out of a constructor. In general this brings us closer to ANF, but when the argument is a literal it is trivial already; and the data representation we generate for `Ptr "blob"#` is just fine. 3. In the float out pass we can float out an expression to avoid repeated allocation or evaluation. But there is no allocation or evaluation associated to an unboxed literal. In https://github.com/ghc/ghc/commit/8f99cfa49be0fc0767f0c73967ff2472de5cfcd6 I've tried disabling the above items 2 and 3 for unboxed string literals. It still produces the desired code in the example of #8472, but it no longer floats the string literals out of, for example, `$trModule` bindings. I'm waiting to see what perf.haskell.org thinks about it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13344#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler