[lldb-dev] Dlopen extremely slow while LLDB is attached

[Scott Funkenhauser via lldb-dev]

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 <jmolenda at 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 at 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 at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180424/52e74b38/attachment.html>