[Lldb-commits] [PATCH] D31172: Move stop info override callback code from ArchSpec into Process

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

> There was a talk at cppcon a few weeks ago from someone at backtrace.io who had some insightful metrics on debugger performance memory consumption, and LLDB had ~2x the memory consumption of GDB.

I haven't seen the paper, but my guess is that this is on linux and lldb wasn't using any accelerator tables for the dwarf of their inferior test program.

gdb was designed before there were any accelerator tables, so in their absence, it will create "partial symbol tables" with the address ranges and globally visible names of each CU.  When details are needed for a specific CU, the psymtab is expanded into a symbol table, symtab.  DWARF is scanned on initial load to create the psymtab names, and then when the symtab is created, it is ingested a CU at a time.  nb: my knowledge of lldb is a decade old at this point, I have not kept up with the project.

lldb was designed with the assumption that we could get these global symbol names from accelerator tables - we would map them into our address space and search for names in them.  When we are interested in a specific type or function or variable, we will read only the DWARF related to that type/function/variable.

In the absence of accelerator tables, I am willing to believe that lldb exhibits poor memory and startup performance -- that was not something we (at apple) concentrated on the performance of.  It's a completely valid area for future work in lldb -- adopting to using accelerator tables other than apple's vendor specific ones.

I suspect, in an absence of concrete information, that the measurement of lldb's memory use being primarily strings, and the perf issues mentioned in this paper, are all due to this non-performant code path on Linux.  If we see these memory issues when there are accelerator tables, then that's a big problem and I'll be shocked if we can actually be out-performed by gdb.  They were the base line that we designed ourselves to do better than.

We can expend a lot of energy on making string tables smaller, and of course I wouldn't object to people working in that direction.  But I think the real solution is to get lldb on non-darwin platforms to be using the accelerator tables that exist and allowing the full design of lldb to work as is intended.   My two cents.


https://reviews.llvm.org/D31172