#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 simonpj): I'm all for making interface-file deserialisation cheaper. But I don't feel that we have a well-characterised problem. ''What exactly is the problem we are trying to solve here?'' Is it ONLY that {{{ x :: Addr# x = "foo"# y :: T y = K x }}} is more expensive than {{{ y :: T y = K "foo"# }}} And if it is more expensive, how much more expensive? And does that cost come from simplifying, spitting out an interface file, code generation, reading in an interface file? I don't think there is much to do with strings here. The same will happen for {{{ x = [True, False, True, ..., True] }}} Perhaps we just don't want to expose the unfolding for a top level constructor. That would be a bit less good on optimisation, but perhaps not a lot. We could measure it. I feel as if we are at risk of taking actions without data to guide them. I'd love to have data. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13344#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler