[Lldb-commits] [PATCH] D51208: [DWARF] Fix dwarf5-index-is-used.cpp

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In https://reviews.llvm.org/D51208#1214743, @dblaikie wrote:

> >> But if LLDB has different performance characteristics, or the default should be different for other reasons - I'm fine with that. I think I left it on for Apple so as not to mess with their stuff because of the MachO/dsym sort of thing that's a bit different from the environments I'm looking at.
> > 
> > These are the numbers from my llvm-dev email in June:
> > 
> >> setting a breakpoint on a non-existing function without the use of
> >>  accelerator tables:
> >>  real    0m5.554s
> >>  user    0m43.764s
> >>  sys     0m6.748s
> >> 
> >> setting a breakpoint on a non-existing function with accelerator tables:
> >>  real    0m3.517s
> >>  user    0m3.136s
> >>  sys     0m0.376s
> > 
> > This is an extreme case,
>
> What was being tested here? Is it a realistic case (ie: not a pathalogical case with an absurd number of symbols, etc)? Using ELF? Fission or not?


These numbers are from linux (so ELF), without fission, and with -fstandalone-debug. The binary being debugged is a debug build of clang. The only somewhat pathological aspect of this is that I deliberately chose a function name not present in the binary when setting the breakpoint.

> How's it compare to GDB performance, I wonder? Perhaps LLDB hasn't been optimized for the non-indexed case and could be - though that'd still potentially motivate turning on indexes by default for LLDB until someone has a motivation to do any non-indexed performance tuning/improvements.

Yes, I could very well be that  LLDB is optimized for the indexed case (or perhaps the other way around, maybe the accelerator tables are optimized for the kind of searches that lldb likes to do). Though I don't mean to say that the non-indexed case is not optimized too -- a number of people over the years have spent a lot of time trying to make the index building step as fast as possible. However, these were all very low-level optimizations (the "improve parallelism by reducing lock contention" kind) and it's possible we might come up with something with better performance characteristics if we looked at a bigger picture. However, that would probably require redesigning a lot of things.

So, with that in mind, I agree we should enable debug_names for -glldb. I'll create a patch for that.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51208