#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): Phab:D2400 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D2400 Comment: Phab:D2400 is also relevant here as it reworks the commit mentioned in comment:18. However, there is further change afoot: On Skype Simon and I discussed the current situation and agreed that it's still not quite right. He has summarized the conclusion on Phab:D2400,
On skype we agreed that
- the the TcIface path doesn't need to even try to look for tuple names because they are encoded specially in interface files. We only need parse tuple names specially in the template haskell route.
- We'll put cons and nil and other special cases into the OriginalNameCache so we don't need to parse them specially here; fewer special cases.
The point is that we needn't worry about the cost of including things like `(:)` and `[]` in the name cache, so we should just remove their cases from `isBuiltInOcc_maybe` and handle them in the usual way. The only cases which we should handle in `isBuiltInOcc_maybe` are those of tuples (of boxed, unboxed, and constraint varieties) and eventually unboxed sums. Additionally Simon proposed that we break up `lookupOrigNameCache` into two variants (names up for debate), * `lookupOrigNameCache'`, which will merely lookup an `OccName` in the name cache, without attempting to resolve built-in syntax (with an assert verifying that we aren't looking up something in `GHC.Tuple`, as definitions defined there aren't in the name cache) * `lookupOrigNameCache`, which will lookup an `OccName` as above, but also attempt to parse out names corresponding to built-in syntax. Then we can use `lookupOrigNameCache'` in the `ReadIface` codepaths, where we know that we should never see built-in syntax (since these names are encoded specially in the interface file symbol table, see `Note [Symbol table representation of names]` in `BinIface`). In the Template Haskell codepaths, it will still be necessary to use `lookupOrigNameCache`, to ensure that things like `mkName "(,)"` work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12357#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler