Thanks for all the feedback and ideas. After Jim's comment about iOS performance, I decided to dig deeper to figure out why it's much slower to attach on Android compared to iOS. I identified an ipv6/ipv4 issue about adb and the simple fix (llvm.org/D79757) brought warm cache attach time down from 23 seconds to ~9 seconds, and cold cache attach time from 120 seconds down to 16-20 seconds!! These are much better numbers, but based on the numbers from Jim, I should probably continue hunting for more Android-specific issues.
One thing I want to try is "settings set plugin.process.gdb-remote.use-libraries-svr4 true". I measure it takes ~600ms to read the list of shared libs without this flag, and it's done 3 times from startup until we hit the first-breakpoint (load all system libraries at attach time; then load base.odex, then load user-lib.so). So, I expect this to shave up to ~1.8 seconds. I don't have any numbers on this yet (does anyone know how much improvement I can expect with this?) About my "don't-load-system-modules" idea (that I mistakenly called "my-code-only" which is apparently something different): Pavel's concerns about not loading modules sounds serious, especially about impacting stability, and I'd like to avoid causing trouble there. So, instead of that, I will try Greg's idea of pre-caching libraries. I'll start with some measurements. I'm working from top-of-tree (I'm trying to build LLDB with libxml2 now). On Wed, May 13, 2020 at 3:08 PM Greg Clayton <clayb...@gmail.com> wrote: > One reason to not only load your libraries is backtraces will be truncated > for any stack frames that go through the system libraries. These tend to be > in the stack traces a lot as we deal with Android all the time at > Facebook... > > Greg > > On May 8, 2020, at 9:07 AM, Emre Kultursay via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi lldb-dev, > > *TL;DR: *Has there been any efforts to introduce something like "Just My > Code" debugging on LLDB? Debugging on Android would really benefit from > this. > > *Details:* > > Native Android apps typically have a single .so file from the user, but > load ~150 system libraries. > > When attaching LLDB remotely to an Android app, a significant amount of > time is spent on loading modules for those system libraries, even with a > warm LLDB cache that contains a copy of all these libraries. > > With a cold LLDB cache, things are much worse, because LLDB copies all > those libraries from the device back to the host to populate its cache. > While one might think this happens only once for a user, things are a bit > worse for Android. There are just too many libraries to copy, making it > very slow, there are new Android releases every year, and users typically > use multiple devices (e.g., x86, x86_64 emulators, arm32, arm64 devices), > and multiple hosts (work, home, laptop/desktop); thereby suffering from > this issue more than necessary. > > If we can eliminate the latency of loading these modules, we can deliver a > much faster debugging startup time. In essence, this can be considered as a > form of Just My Code debugging. > > *Prototype and Experiments* > > I built a simple prototype that only loads a single user module, and > totally avoids loading ~150 system modules. I ran it on my Windows host > against an Android emulator to measure the end to end latency of "Connect + > Attach + Resume + Hit 1st breakpoint immediately" . > > - For warm LLDB cache: > - Without just-my-code: 23 seconds > - With just-my-code: 14 seconds > - For cold LLDB cache: > - Without just-my-code: 120 seconds > - With just-my-code: 16 seconds > > > I want to solicit some feedback and gather thoughts around this idea. It > would be great if there are any existing alternatives in LLDB to achieve my > goal, but otherwise, I can implement this on LLDB and I'd appreciate it if > anyone has any advice on how to implement such a feature. > > Thanks. > -Emre > > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev