[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

llunak added a comment. In D68549#1710986 , @teemperor wrote: > We could also just let the allocator take a parameter so that is increases > the growth size to do it every Nth slab (N=1 for us) and set a slightly > larger starting size. Heh, I wasn't e

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

teemperor added a comment. (Seems like my previous comment was cut off in the middle for some reason?) We could also just let the allocator take a parameter so that is increases the growth size to do it every Nth slab (N=1 for us) and set a slightly larger starting size. By the way, if I look

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

labath added a comment. In D68549#1710744 , @llunak wrote: > Thinking more about this, maybe this is really not the right place and the > change should be done in BumpPtrAllocator? To me it seems rather unreasonable > that it would double the allocation

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

llunak added a comment. Thinking more about this, maybe this is really not the right place and the change should be done in BumpPtrAllocator? To me it seems rather unreasonable that it would double the allocation size only after 128 allocations. Surely by the time it has already allocated 128*4

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

llunak added a comment. Oh, I somehow completely missed the fact that there are 256 of those :-/. In that case my numbers are way too much. Can you easily benchmark with different numbers? I think something like 131072 for BumpPtrAllocator (to still be large enough for the mmap threshold) could

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

labath added a comment. Yeah, allocating 256MB sounds a bit too much, particularly for lldb-server (ideally, I'd remove ConstString from lldb-server completely, but that's a different story). The reason for 256 string pools was to avoid/reduce locking contention when accessing the pool, but tha

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

teemperor added a comment. Oh, I wasn't aware we already had that in the allocator. I looked at the source and it seems that we need to first create about 1024 slabs before we reach the 1MiB limit, which means we need 256 * 1024 = 262144 slabs in LLDB due to the 256 different string pools. Re

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

joerg added a comment. I'm a bit puzzled by the need for this change. The bump allocator already has logic to do power-of-two scaling for the allocation, so I wonder why it doesn't work properly here. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

teemperor added subscribers: xiaobai, teemperor. teemperor added a comment. This patch actually made the RSS memory in our benchmarks go up by quite a bit (see lldb-bench ). The reason is that while we only create 1MiB chunks in the new allocator, we

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

This revision was automatically updated to reflect the committed changes. Closed by commit rGe2ca7cb504a8: make ConstString allocate memory in non-tiny chunks (authored by llunak). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68549/new/ https://rev

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

clayborg accepted this revision. clayborg added a comment. Nice! If we run into any issues we can make this a global debugger setting. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68549/new/ https://reviews.llvm.org/D68549 __

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

llunak added a comment. In D68549#1700019 , @aprantl wrote: > This makes sense to me. We may need to make this configurable for low-memory > hosts at some point. Note that the memory usage shouldn't be as bad as it might look. As long as the BumpPtrAll

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

aprantl accepted this revision. aprantl added a comment. This revision is now accepted and ready to land. This makes sense to me. We may need to make this configurable for low-memory hosts at some point. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68549/new/

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

aprantl added a comment. I assume you experimented with many different values, and these are the best tradeoff? Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68549/new/ https://reviews.llvm.org/D68549 ___ lldb-com

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

llunak updated this revision to Diff 223414. llunak added a comment. Increased default number of buckets for StringMap too. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68549/new/ https://reviews.llvm.org/D68549 Files: lldb/source/Utility/ConstString.cpp

[Lldb-commits] [PATCH] D68549: make ConstString allocate memory in non-tiny chunks

llunak created this revision. llunak added a reviewer: clayborg. llunak added a project: LLDB. Herald added subscribers: lldb-commits, JDevlieghere, aprantl. BumpPtrAllocator allocates in 4KiB chunks, which with any larger project is going to result in a large number of allocations. Increasing al