No liblldb.so didn't have any debug information, I made sure to strip it. With debug information it was 1.7GB which took way too long to load for a practical reproduction case.
On Tue, Apr 24, 2018 at 3:36 PM Jason Molenda <jmole...@apple.com> wrote: > Was liblldb.so build with debug information? You're probably looking at > lldb scanning the DWARF to make up its symbol table. That would be re-used > on subsequent reruns so you're only seeing the cost that first time > through. gdb may be using the standard dwarf accelerator tables, or it may > be delaying the cost of the scan until you try to do something like a > breakpoint by name. > > > J > > > On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hey guys, > > > > I'm trying to track down an issue I'm seeing where dlopen takes > significantly longer to execute when LLDB is attached vs GDB (I've attached > a simple program that I used to reproduce the issue). > > I was wondering if anybody had any idea what might be contributing to > the additional execution time? > > > > Running without any debugger attached: > > $ ./lldb-load-sample > > Handle: 0x555555768c80 > > Done loading. 848.27ms > > $ ./lldb-load-sample > > Handle: 0x555555768c80 > > Done loading. 19.6047ms > > > > I noticed that the first run was significantly slower than any > subsequent runs. Most likely due to some caching in Linux. > > > > > > For LLDB: > > (lldb) file lldb-load-sample > > Current executable set to 'lldb-load-sample' (x86_64). > > (lldb) run > > Process 82804 launched: '/lldb-load-sample' (x86_64) > > Handle: 0x555555768c80 > > Done loading. 5742.78ms > > Process 82804 exited with status = 0 (0x00000000) > > (lldb) run > > Process 83454 launched: '/lldb-load-sample' (x86_64) > > Handle: 0x555555768c80 > > Done loading. 19.4184ms > > Process 83454 exited with status = 0 (0x00000000) > > > > I noticed that subsequent runs were much faster (most likely due to some > caching in Linux / LLDB), but that isn't relevant in my situation. Exiting > LLDB and starting a new LLDB process still has an extremely long first run > (In this case ~5.5s). There are other real world cases (initializing Vulkan > which does a bunch of dlopens) where this can add 10s of seconds really > slowing down iteration time. > > > > > > For GDB: > > (gdb) file lldb-load-sample > > Reading symbols from a.out...done. > > (gdb) run > > Starting program: /lldb-load-sample > > Handle: 0x555555768c80 > > Done loading. 79.7276ms > > [Inferior 1 (process 85063) exited normally] > > (gdb) run > > Starting program: /lldb-load-sample > > Handle: 0x555555768c80 > > Done loading. 80.325ms > > [Inferior 1 (process 85063) exited normally] > > > > As you can see the first run is slightly slower than running without a > debugger attached, but it's not enough to be noticeable. > > > > Thanks, > > Scott > > > > <lldb-load-sample.cc>_______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev