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

[Raphael Isemann via Phabricator via lldb-commits]

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 at the flame graph for lldb starting up and setting a break point in an LLDB debug binary <https://teemperor.de/lldb-bench/data/extern-lldb-bt.svg>, it seems that on the benchmark server we spent less than 0.5% of the startup time in that allocator function and much more time in that other ConstString overhead (the double-hashing to find the StringPool, the different locking). I'm curious why the allocator logic is so disproportionally slow on your setup (0.5% vs 10-20%). The only real work we do in the allocator is calling malloc, so I assume calling malloc is much more expensive on your system?

> Can you easily benchmark with different numbers?

Sadly not, but just running LLDB to attach to a LLDB debug build and running this lldb command list <https://github.com/Teemperor/lldb-bench/blob/master/benchmarks/extern-lldb-bt/commands.lldb> should replicate the most important benchmark.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68549/new/

https://reviews.llvm.org/D68549