#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 bgamari): I had a quick look. I am seeing significant increases in compiler allocations as early as typecheck/rename. For instance, in the case of `T5837` I see, ||= Phase =||= Before patch (megabytes) =||= After patch (megabytes) =|| || Parser || 1.069 || 1.069 || || Renamer/typechecker || 117.168 || 125.031 || || Desugar || 4.127 || 4.155 || || Simplifier || 0.746 || 0.811 || || CoreTidy || 2.277 || 2.516 || || CorePrep || 0.287 || 0.299 || || CodeGen || 6.804 || 6.845 || The only difference in the simplified core is due to the strings associated with the Typeable bindings. Before the patch we had, {{{#!hs $trModule4 :: GHC.Types.TrName $trModule4 = GHC.Types.TrNameS "T5837"# }}} Now we have, {{{#!hs $trModule3 :: GHC.Prim.Addr# $trModule3 = "T5837"# $trModule4 :: GHC.Types.TrName $trModule4 = GHC.Types.TrNameS $trModule3 }}} While some small fraction of the allocations change after CodePrep is attributable to the fact that StgSyn got slightly larger (since we now have a separate type for top-level bindings), this doesn't explain the difference during renaming/typechecking. I wonder if some of these newly floating string literals have snuck into interface files? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13344#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler