#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): I've put up a few attempts at reducing some of the costs associated with `FastString` operations and in particular `isBuiltInOcc_maybe`. The most promising so far is Phab:D2385, which reworks `isBuiltInOcc` to avoid unpacking the name being checked. It does this by moving the implementation away from `String` pattern matching and towards a `FastString` lookup in a `UniqFM`. Initial indications suggest this reduces allocations by around 5% when compiling `nofib/real/fulsom/Shape.hs`. Another thing I noticed while tracking this down is the behavior of `concatFS`, which unpacks the the `FastString`s being concatenated and then builds a new `FastString` from the resulting list. It seems like there might be slightly better constant factors to be had by simply concatenating the `ByteString`s themselves. I have tried reworking this in Phab:D2384, although I don't yet have solid numbers characterizing its effect. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12357#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler