[GHC] #13344: Core string literal patch regresses compiler performance considerably

[GHC]

#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