maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

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
This commit is contained in:
Raphael Isemann 2019-10-17 00:02:32 +00:00
parent f4f120125e
commit 755420c085
1 changed files with 2 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
lldb/source/Utility/ConstString.cpp
View File

@ -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;