#12357: Increasing maximum constraint tuple size significantly blows up compiler allocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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): It appears that much of the remaining difference is due to the construction of the superclass selector `OccName`s, which looks like this, {{{#!hs mkSuperDictSelOcc :: Int -- ^ Index of superclass, e.g. 3 -> OccName -- ^ Class, e.g. @Ord@ -> OccName -- ^ Derived 'Occname', e.g. @$p3Ord@ mkSuperDictSelOcc index cls_tc_occ = mk_deriv varName "$p" (show index ++ occNameString cls_tc_occ) }}} This is rather inefficient as we first decode the class's `OccName`, then reencode it. After fixing `concatFS` with Phab:D2384 and redefining this helper as {{{#!hs mkSuperDictSelOcc index cls_tc_occ = mkOccNameFS varName $ concatFS [fsLit "$p", fsLit $ show index, occNameFS cls_tc_occ] }}} I find that allocations return to 96MBytes, which is very close to the allocations prior to the superclass constraint patch. I suspect that this rework should be performed to all of the helpers in `OccName`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12357#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler