[GHC] #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations

[GHC]

#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