19735, "bmcdonald3", "How should we allow users to override hash table resizing policies?", "2022-05-02T18:14:25Z"
Summary
Today, our internal chpl__hashtable (which is used by associative domains, map, and set) resizes once exceeding 50% capacity by default through a value called resizeThreshold, though this value of 50% is rather arbitrary. Based on a users memory or performance concerns, changing this value can be valuable. Map and set can override this with a resizeThreshold argument in their initializers, but there is no way to do so for associative domains today, and changing the map/set values also requires recompilation. We are hoping to expose this in a more flexible way and need to decide on method and naming.
Proposals
Proposal 1: a single private config const in the internal ChapelHashtable module
This has the flexibility of setting one value for all uses of chpl__hashtable for a simple way to modify the default resizeThreshold. The main problem is that the user will have to fully qualify the path to the internal module to set this value, which
Proposal 2: 3 separate private config const values in set, map, associative domain
This keeps the values to the user modules and makes it more explicit, but becomes more complicated and provides arguably less value than just having the singl chpl__hashtable config value.
Proposal 3: use something besides a private config const, but with either of the above proposals
Using a param would make the value not show up in --help output and there could be other benefits/combinations that I have not grasped the benefits of yet, so please mention if you have concerns with private config const.
Names
-
resizeThreshold- verbose, describes behavior, matches set/map initializers
-
rThresh- slightly shorter, doesn't conflict with set/map initializer names
- something else? (please propose if you don't like either of these names)