[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates

[teemperor]

Summary

We currently do far more malloc calls than necessary in the ConstString BumpPtrAllocator. This is due to the 256 BumpPtrAllocators
our ConstString implementation uses internally which end up all just receiving a small share of the total allocated memory
and therefore keep allocating memory in small chunks for far too long. This patch fixes this by increasing the rate at which we increase the
memory chunk size so that our collection of BumpPtrAllocators behaves in total similar to a single BumpPtrAllocator.

[teemperor]

@llunak can you test how this affects your runtime for the use case you wanted this for?

[teemperor]

(This patch is otherwise ready to land)

[llunak]

I'm back at using gdb for the time being, so I'd have to build code with debuginfo suitable for lldb, which would take some time. But given that this is more or less the same as I did before, I don't see why this shouldn't work similarly. Thank you for getting these changes in.

lldb/source/Utility/ConstString.cpp

 #include <inttypes.h>
 #include <stdint.h>
 #include <string.h>
 
 using namespace lldb_private;
 
 class Pool {
 public:
+  /// The default BumpPtrAllocatorImpl slab size.
+  static const size_t AllocatorSlabSize = 4096 * 4;
+  /// Every Pool has its own allocator which receives an equal share of
+  /// the ConstString allocations. This means that when allocating many
+  /// ConstStrings, every allocator sees only its small share of allocations and
+  /// assumes LLDB only allocated a small amount of memory so far. In reality
+  /// LLDB allocated a total memory that is N times as large as what the
+  /// allocator sees (where N is the number of string pools). This causes that
+  /// the BumpPtrAllocator continues a long time to allocate memory in small
+  /// chunks which only makes sense when allocating a small amount of memory
+  /// (which is true from the perspective of a single allocator). On some
+  /// systems doing all these small memory allocations causes LLDB to spend
+  /// a lot of time in malloc, so we need to force all these allocators to
+  /// behave like one allocator in terms of scaling their memory allocations
+  /// with increased demand. To do this we set the growth delay for each single
+  /// allocator to a rate so that our pool of allocators scales their memory
+  /// allocations similar to a single BumpPtrAllocatorImpl.
+  ///
+  /// Currently we have 256 string pools and the normal growth delay of the
+  /// BumpPtrAllocatorImpl is 128 (i.e., the memory allocation size increases
+  /// every 128 full chunks), so by changing the delay to 1 we get a
+  /// total growth delay in our allocator collection of 256/1 = 256. This is
+  /// still only half as fast as a normal allocator but we can't go any faster
+  /// without decreasing the number of string pools.
+  static const size_t AllocatorGrowthDelay = 1;
+  typedef llvm::BumpPtrAllocatorImpl<llvm::MallocAllocator, AllocatorSlabSize,
+                                     AllocatorSlabSize, AllocatorGrowthDelay>
+      Allocator;
   typedef const char *StringPoolValueType;
-  typedef llvm::StringMap<StringPoolValueType, llvm::BumpPtrAllocator>
-      StringPool;
+  typedef llvm::StringMap<StringPoolValueType, Allocator> StringPool;
   typedef llvm::StringMapEntry<StringPoolValueType> StringPoolEntryType;
 
   static StringPoolEntryType &
   GetStringMapEntryFromKeyData(const char *keyData) {
     return StringPoolEntryType::GetStringMapEntryFromKeyData(keyData);
   }
 
   static size_t GetConstCStringLength(const char *ccstr) {