<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>