I wonder if making indexing multi-threaded has solved speed issues? > On Dec 21, 2017, at 8:54 AM, Pavel Labath <lab...@google.com> wrote: > > That's not the case, the nested debugger get's stopped in > CommandObjectTargetCreate::DoExecute before it even touches the > /bin/ls file. I could have passed anything there (probably /bin/ls > wasn't the best choice though), it's just this was the easiest thing I > came up with for stopping at a place with a non-trivial backtrace and > local variables. > > I've verified that in each test scenario the (outer) debugger prints > out a reasonable backtrace and local variable values. > > > > On 21 December 2017 at 16:46, Greg Clayton <clayb...@gmail.com> wrote: >> >>> On Dec 21, 2017, at 8:23 AM, Pavel Labath <lab...@google.com> wrote: >>> >>> On 21 December 2017 at 10:45, Pavel Labath <lab...@google.com> wrote: >>>> I'm not sure now whether you're suggesting to use the dsymutil >>>> approach just to gauge the potential speedup we can obtain and get >>>> people interested, or as a productized solution. If it's the first one >>>> then I fully agree with you. Although I think I can see an even >>>> simpler way to estimate the speedup: build lldb for mac with apple >>>> indexes disabled and compare its performance to a vanilla one. I'm >>>> going to see if I can get some numbers on this today. >>> >>> >>> Here's some data I gathered today. What I did was I disabled apple >>> accelerator table parsing in ObjectFileELF (patch is in the >>> attachment) and then I compared startup time when debugging lldb with >>> itself. Specifically I used an Release (optimized) lldb to open a >>> Debug lldb, set a breakpoint, hit it, display local variables and >>> backtrace. The precise command is: >>> $ time opt/bin/lldb -o "br set -n DoExecute" -o "pr la" -o "bt" -o "fr >>> var" -b -- dbg/bin/lldb -- /bin/ls >>> I ran the command three times and chose the median result. >>> >>> Before I show the measurements I have to give one big disclaimer: The >>> debugger with accelerator tables disabled does not appear to be fully >>> functional. Specifically most (all?) of the objc tests in the test >>> suite hang, and also 50 additional tests fail (the failures seem to be >>> related to expression evaluation, mostly). However, I think the fact >>> that the remaining ~2000 tests passed means that we still have been >>> reading the dwarf parsing functionality is reasonably intact. >>> >>> Now, the numbers: >>> vanilla dSYM >>> real 0m7.774s >>> user 0m15.261s >>> sys 0m1.228s >>> >>> >>> ===== >>> vanilla no-dSYM >>> real 0m5.987s >>> user 0m4.919s >>> sys 0m0.698s >>> >>> >>> >>> ===== >>> no-apple dSYM >>> real 0m7.616s >>> user 0m14.812s >>> sys 0m1.208s >>> >>> >>> ===== >>> no-apple no-dSYM >>> real 0m45.520s >>> user 0m31.096s >>> sys 0m11.101s >>> >>> >>> >>> It's not fully clear to me how to interpret this data. The difference >>> between having the accelerator tables and not is approximately what I >>> would expect (a lot) in the no-dSYM scenario, and I believe this is >>> the kind of speedup we should expect on linux. However, there are also >>> some question marks, like why is the time virtually unchanged in case >>> we have a dSYM bundle around? Also, the difference between having dSYM >>> and not is quite large (and opposite to what I would expect) in >>> "vanilla" case. >>> <apple.diff> >> >> So results might be wrong because you can't debug /bin/ls and many commands >> might just not be happening (as soon as you get an error, the command stop >> happening). /bin/ls is Apple signed and SIP (system integrity protection) >> will stop you from actually debugging it. Did you disable SIP? >>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
