[GHC] #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations
GHC
ghc-devs at haskell.org
Tue Jul 5 09:31:47 UTC 2016
#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
More information about the ghc-tickets
mailing list