#13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | 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 dfeuer): I've spent a bit more time looking at T212425. A couple things I've noticed: One reason we're getting more terms and types is pretty obvious. Where we used to have {{{#!hs lvl3_r2p3 = unpackCString# "T12425.hs"# }}} we now have {{{#!hs lvl6_r2GO = "T12425.hs"# lvl7_r2GP = unpackCString# lvl6_r2GO }}} Another reason is less obvious. We've always had multiple copies of some strings, but now we're getting ''more'' repeats. I don't know why that is. I also don't really if any of this is actually responsible for the allocation change, but it could be responsible for some of it. It looks like there are more terms, types and allocations for every stage past parsing, but float out is (unsurprisingly) prominent. My big question is why we're allowing these literals to be duplicated in the first place. I would think, naively perhaps, that we could assign each of them a unique, top-level identity from the start, and merely mark use- sites as inline or not, rather than actually inlining. When floating out, we could merge any two bindings in the same scope that refer to the same string identity. Those top-level identities would ultimately be resolved as either "inline-only" (not appearing in any unfoldings, etc., so they can be discarded) or otherwise. Of course we'd need to deal with the fact that built-in rules and such may be able to produce new literals, but I would think that relatively straightforward. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13226#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

My big question is why we're allowing these literals to be duplicated in

#13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | 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 simonpj): the first place Good question. Can you show a repro case, please? Returning to your first point, the extra binding is reasonable. After all, if we had {{{ x = f "foo#" y = g "foo#" }}} we might expect CSE to share those literals, and floating them to the top does just that. Moreover the final code is the same either way. But if `f` and `g` were identical (say `unpackCString#`) then we'd CSE `x` and `y` anyway. So we could choose not to float string literals unless they escaped a lambda. That would be easy to do if we wanted to try it. (We want to take them out of lambdas to allow the lambda to be inlined without duplicating the string.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13226#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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 bgamari): I'm not sure what you mean. Which threshold are you referring to? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13226#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler