Revert "make ConstString allocate memory in non-tiny chunks"

As discussed in https://reviews.llvm.org/D68549, the actual issue
here seems to be that the BumpPtrAllocator is growing far too slow
because of the 256 different StringPools used as the backend for ConstString.
At the same time the original patch made ConstString allocate memory in
256MiB slabs for the same reason, meaning that the RSS usage of LLDB increased
by a few hundred MiB for all users without bringing any noticeable speedup
for most of them.

llvm-svn: 375062

1 files changed, 2 insertions, 7 deletions

diff --git a/lldb/source/Utility/ConstString.cpp b/lldb/source/Utility/ConstString.cpp
index 238fd7bdd28..2516ecf6a98 100644
--- a/lldb/source/Utility/ConstString.cpp
+++ b/lldb/source/Utility/ConstString.cpp
@@ -31,10 +31,7 @@ using namespace lldb_private;
 class Pool {
 public:
   typedef const char *StringPoolValueType;
-  // BumpPtrAllocator allocates in 4KiB chunks, any larger C++ project is going
-  // to have megabytes of symbols, so allocate in larger chunks.
-  typedef llvm::BumpPtrAllocatorImpl<llvm::MallocAllocator, 1048576> Allocator;
-  typedef llvm::StringMap<StringPoolValueType, Allocator>
+  typedef llvm::StringMap<StringPoolValueType, llvm::BumpPtrAllocator>
       StringPool;
   typedef llvm::StringMapEntry<StringPoolValueType> StringPoolEntryType;
 
@@ -155,9 +152,7 @@ protected:
 
   struct PoolEntry {
     mutable llvm::sys::SmartRWMutex<false> m_mutex;
-    // StringMap by default starts with 16 buckets, any larger project is
-    // going to have many symbols, so start with a larger value.
-    StringPool m_string_map = StringPool( 65536 );
+    StringPool m_string_map;
   };
 
   std::array<PoolEntry, 256> m_string_pools;