<div dir="ltr"><div dir="auto"><div>Thanks Raphael for the pointers, I will take a look.</div><div dir="auto"><br></div><div dir="auto">I just noticed I forgot to attach the actual patch I prepared ;)</div><div dir="auto">Here it is.</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021, 5:02 PM Raphael “Teemperor” Isemann <<a href="mailto:teemperor@gmail.com" target="_blank">teemperor@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">I can't help with any of the requested feedback, but the last time I looked at a benchmark involving ManualDWARFIndex, the ManualDWARFIndex::IndexUnit spent about 40% of its runtime just constructing ConstString. Half of that 40% (so, 20% total time) was just spend contesting/locking the locks for ConstString's global string pools. Refactoring the code to not having to reaquire a contested global lock for every DIE might help with improving startup time.<div><br></div><div>Cheers,</div><div>- Raphael<br><div><br><blockquote type="cite"><div>On 29 Jan 2021, at 16:25, Lasse Folger via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" rel="noreferrer" target="_blank">lldb-commits@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><div>Hi lldb devs,</div><div><br></div><div>We experienced some issues when debugging large binaries.</div><div>The startup time of lldb for large binaries is long (tens of seconds).</div><div>One of the reasons is that the <i>ManualDWARFIndex::Index()</i> function is executed synchronously and thus blocks during startup.</div><div>We would like to change this to an async task. Let me know if you have any concerns.</div><div><br></div><div>I prepared a small patch to schedule the index creation async.</div><div><br></div><div>I would like to have feedback on three parts:</div><div><ol><li style="margin-left:15px">In <i>ManualDWARFIndex::Preload() </i>I capture <i>this</i> of the <i>ManualDWARFIndex</i>. As far as I could tell this is not a problem since the index is not relocated or deleted. However, I'm not that familiar with the architecture. Are there cases when the object is relocated or deleted before lldb stops?</li><li style="margin-left:15px">I use the <i>Module </i>mutex for synchronization because I didn't want to introduce a mutex in <i>ManualDWARFIndex </i>or <i>DWARFIndex</i>. Do you think this locking granularity is fine or should I create a dedicated mutex for it? Furthermore, I looked through the implementation of ManualDWARFIndex::<i>Index()</i> and couldn't find any locking function in there. However, I might have missed something (or some of the underlying implementations change in the future) and there is a danger for a deadlock.</li><li style="margin-left:15px"><i>ManualDWARFIndex::Index()</i> creates a thread pool internally. This means if multiple calls to<i> ManualDWARFIndex::Index() </i>are executed at the same time, there might be more threads than cores. This might cause contention and decrease efficiency. (Thanks to Andy for pointing this out).<br></li></ol><div>Please let me know what you think and if I should change something.</div></div><div><br></div><div><br clear="all"><div><div dir="ltr"><div dir="ltr">kind regards,<div>Lasse</div></div></div></div></div></div>
_______________________________________________<br>lldb-commits mailing list<br><a href="mailto:lldb-commits@lists.llvm.org" rel="noreferrer" target="_blank">lldb-commits@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits</a><br></div></blockquote></div><br></div></div></blockquote></div></div></div>
</div>