#12357: Increasing maximum constraint tuple size significantly blows up compiler allocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch 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: | Phab:D2414 -------------------------------------+------------------------------------- Comment (by bgamari): Sadly I mentioned the wrong commit in the commit message. Here is the merged commit for Phab:D2414, In [changeset:"9513fe6bdeafd35ca1a04e17b5f94732516766aa/ghc" 9513fe6/ghc]: {{{ Clean up interaction between name cache and built-in syntax This cleans up various aspects of the handling of built-in syntax in the original name cache (hopefully resulting in a nice reduction in compiler allocations), * Remove tuple types from original name cache: There is really no reason for these to be in the name cache since we already handle them specially in interface files to ensure that we can resolve them directly to Names, avoiding extraneous name cache lookups. * Sadly it's not possible to remove all traces of tuples from the name cache, however. Namely we need to keep the tuple type representations in since otherwise they would need to be wired-in * Remove the special cases for (:), [], and (##) in isBuiltInOcc_maybe and rename it to isTupleOcc_maybe * Split lookupOrigNameCache into two variants, * lookupOrigNameCache': Merely looks up an OccName in the original name cache, making no attempt to resolve tuples * lookupOrigNameCache: Like the above but handles tuples as well. This is given the un-primed name since it does the "obvious" thing from the perspective of an API user, who knows nothing of our special treatment of tuples. Arriving at this design took a significant amount of iteration. The trail of debris leading here can be found in #11357. Thanks to ezyang and Simon for all of their help in coming to this solution. Test Plan: Validate Reviewers: goldfire, simonpj, austin Reviewed By: simonpj Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2414 GHC Trac Issues: #11357 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12357#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler