Reduce HashSet's kMinBuckets to 10

HashSet (and its child classes like HashMap) used to have a big
kMinBuckets which slowed down compilation times. The idea
behind such number was to start with a big table and avoid
resizing. However, this is not efficient as e.g. we sometimes
create a table way bigger than what we need.

This also has a performance impact in cases where we clear
HashMaps to be reused. The problem there is that `clear()`
will deallocate the storage which will be reallocated when
something is inserted. Since kMinBuckets was 1000, it meant that
said first insertion would be very costly.

From local compiles, it improves ~1.3-2% of compile time. Both
Scheduling and WriteBarrierElimination greatly benefit from this
change.

Bug: 393108375
Test: art/test/testrunner/testrunner.py --host --64 -b --optimizing
Change-Id: I49b305145398bb748a3bc6153a3c281c758eba6f

1 files changed, 1 insertions, 1 deletions

diff --git a/libartbase/base/hash_set.h b/libartbase/base/hash_set.h
index 91766a75d1..b4979d56af 100644
--- a/libartbase/base/hash_set.h
+++ b/libartbase/base/hash_set.h
@@ -191,7 +191,7 @@ class HashSet {
 
   static constexpr double kDefaultMinLoadFactor = 0.4;
   static constexpr double kDefaultMaxLoadFactor = 0.7;
-  static constexpr size_t kMinBuckets = 1000;
+  static constexpr size_t kMinBuckets = 10;
 
   // If we don't own the data, this will create a new array which owns the data.
   void clear() {