<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 24, 2018 at 3:36 PM Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.  <br>
<br>
<br>
J<br>
<br>
> On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> Hey guys,<br>
> <br>
> 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).<br>
> I was wondering if anybody had any idea what might be contributing to the additional execution time?<br>
> <br>
> Running without any debugger attached:<br>
> $ ./lldb-load-sample<br>
> Handle: 0x555555768c80<br>
> Done loading. 848.27ms<br>
> $ ./lldb-load-sample<br>
> Handle: 0x555555768c80<br>
> Done loading. 19.6047ms<br>
> <br>
> I noticed that the first run was significantly slower than any subsequent runs. Most likely due to some caching in Linux.<br>
> <br>
> <br>
> For LLDB:<br>
> (lldb) file lldb-load-sample<br>
> Current executable set to 'lldb-load-sample' (x86_64).<br>
> (lldb) run<br>
> Process 82804 launched: '/lldb-load-sample' (x86_64)<br>
> Handle: 0x555555768c80<br>
> Done loading. 5742.78ms<br>
> Process 82804 exited with status = 0 (0x00000000) <br>
> (lldb) run<br>
> Process 83454 launched: '/lldb-load-sample' (x86_64)<br>
> Handle: 0x555555768c80<br>
> Done loading. 19.4184ms<br>
> Process 83454 exited with status = 0 (0x00000000)<br>
> <br>
> 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.<br>
> <br>
> <br>
> For GDB:<br>
> (gdb) file lldb-load-sample<br>
> Reading symbols from a.out...done.<br>
> (gdb) run<br>
> Starting program: /lldb-load-sample<br>
> Handle: 0x555555768c80<br>
> Done loading. 79.7276ms<br>
> [Inferior 1 (process 85063) exited normally]<br>
> (gdb) run<br>
> Starting program: /lldb-load-sample<br>
> Handle: 0x555555768c80<br>
> Done loading. 80.325ms<br>
> [Inferior 1 (process 85063) exited normally]<br>
> <br>
> As you can see the first run is slightly slower than running without a debugger attached, but it's not enough to be noticeable.<br>
> <br>
> Thanks,<br>
> Scott<br>
> <br>
> <lldb-load-sample.cc>_______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div>