[GHC] #14854: The size of FastString table is suboptimal for large codebases

[GHC]

#14854: The size of FastString table is suboptimal for large codebases
-------------------------------------+-------------------------------------
        Reporter:  niteria           |                Owner:  watashi
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:
      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:D5211
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"5126764be614cc43b435e3f5ff34ea593c30269a/ghc"
 5126764b/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="5126764be614cc43b435e3f5ff34ea593c30269a"
 Rewrite FastString table in concurrent hashtable

 Summary:
 Reimplement global FastString table using a concurrent hashatable with
 fixed size segments and dynamically growing buckets instead of fixed size
 buckets.

 This addresses the problem that `mkFastString` was not linear when the
 total number of entries was large.

 Test Plan:
 ./validate

 ```
 inplace/bin/ghc-stage2 --interactive -dfaststring-stats < /dev/null
 GHCi, version 8.7.20181005: http://www.haskell.org/ghc/  :? for help
 Prelude> Leaving GHCi.
 FastString stats:
     segments:          256
     buckets:           16384
     entries:           7117
     largest segment:   64
     smallest segment:  64
     longest bucket:    5
     has z-encoding:    0%
 ```

 Also comapre the two implementation using

 {P187}

 The new implementation is on a par with the old version with different
 conbination of parameters and perform better when the number of
 FastString's are large.

 {P188}

 Reviewers: simonmar, bgamari, niteria

 Reviewed By: simonmar, bgamari

 Subscribers: rwbarton, carter

 GHC Trac Issues: #14854

 Differential Revision: https://phabricator.haskell.org/D5211
 }}}

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