[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):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 See [https://phabricator.haskell.org/D2385#69455 Omer's comments] on the
 (now-closed) Phab patch.  I'm responding here because Trac is a more
 durable medium than closed code reviews.

 I have not been paying proper attention to this ticket.  But the solution
 embodied here (and now in HEAD) really isn't right.  The new situation in
 `lookupOrigNameCache` is this:

 1. Look up the `OccName` in fixed finite map, designed to catch tuples
 2. If that fails, look up the (`Module`, `OccName`) pair in the original
 name cache.  This is just a two-level finite map: first look up the
 `Module` then the `OccName`.

 So now, for every non-tuple, we do two lookups, in step 1 and step 2 resp.
 This is obviously bad. If we are going to have a finite map for tuples,
 just populate the original-name cache with tuples, and do step (2) alone.

 Even if tuples are treated specially somehow, as Omer says, it would be be
 far better to first spot that the `Module` is `GHC.Tuple` and only then do
 tuple-processing.

 But what we have now is (a) more complicated and (b) slower than this.

 For tuples, maybe it's ok to populate the cache with 62 tycons and 62
 datacons.  For for unboxed sums we'll have 62*62 data cons, which we might
 consider too many.  It may be that a little hand-written parser, working
 directly on `ByteString` would be better. But regardless that should be a
 decision that affects only the code path when we reallydo have a tuple,
 not everything.

 Another option that we explored in the past was to have a special
 interface-file representation for these name-families (tuples and sums).
 Perhaps
 {{{
 data IfaceType = ...
   | IfaceTuple Boxity Arity
 }}}
 meaning just an occurence of the naked `TyCon`.  Now the string
 `GHC.Tuple.(,,,)` would never occur, so this entire question would not be
 relevant for interface file serialisation and deserialisation.  (We'd
 still need that parser for Template Haskell.)
 I'm not sure why we abandoned that approach.

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