[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:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 In comment:21 I described the plan. Now I'll describe the reality, which
 includes a few wrinkles.

 As it turns out, we actually **do** include almost all of the tuple types
 in the original name cache. We can see this by noticing that `newHscEnv`
 initializes the namecache as `(initNameCache us allKnownKeyNames)`, where
 `allKnownKeyNames` includes,
 {{{#!hs
 knownKeyNames = concat
   [ ...
   , concatMap tycon_kk_names typeNatTyCons

   , concatMap (tycon_kk_names . tupleTyCon Boxed) [2..mAX_TUPLE_SIZE]  --
 Yuk
   , cTupleTyConNames
   , ...
   ]

 allKnownKeyNames = knownKeyNames ++ ...
 }}}

 Consequently, if you remove the `isBuiltInOcc_maybe` checks entirely
 things //almost// continue to work; almost because you will note that
 unboxed tuples are missing. This had led me to assume that all tuples were
 missing from the name cache. However, if you add unboxed tuples to
 `knownKeyNames` things validate without any trouble.

 So, the question now is whether we want to change this by removing tuples
 from the original name cache. To answer this let's consider what this
 would entail: I believe the only sensible way to implement comment:21
 would be to filter out tuples from `allKnownKeyNames` when initializing
 the name cache. I specifically do not propose to remove tuples from
 `allKnownKeysNames` since the `TcTypeable` implementation relies on them
 being present so it knows to generate type representations for them. Is
 filtering them out worthwhile? I'll try to take some measurements to find
 out, but I'm not entirely convinced (at least for tuples; unboxed sums may
 be another story).

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12357#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler