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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
