#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 looks like much of the trouble is that we are unpacking `OccNames` in `isBuiltInOcc_maybe`, which gets called in `LoadIface.loadDecl` by `IfaceEnv.lookupOrig`. This results in a great deal of allocations by `utf8DecodeString`, which eagerly decodes the entire string buffer into a `[Char]`. This eager behavior seems a bit silly. Unfortunately, I made a few quick attempts at making this decoding lazy but sadly it typically hurt allocations more than it helped due to thunk allocations It also seems a bit silly that we inspect the name itself to determine whether it is built-in. Afterall, there is a finite universe of built-in `OccName`s and we already know the `FastString` hash of the `OccName` we are testing, so it seems like this really should just be a `UniqFM` lookup. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12357#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler