#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 ):
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
