<div dir="ltr">Hey Piotr,<div><br></div><div>Thanks for taking a look at that. I'll have a run through it today or tomorrow. I had noticed some really slow backtrace times on relatively simple Linux x86_64 cores but just hadn't had the cycles to look at it yet.</div>
<div><br></div><div>I'll get back on this once I have a chance to look at it. (If anybody else has a chance to look at it before me, feel free).</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 23, 2014 at 12:07 PM, Piotr Rak <span dir="ltr"><<a href="mailto:piotr.rak@gmail.com" target="_blank">piotr.rak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div>Here is rebased version of same patch - so it applies cleanly on top of:<div>
<br></div><div><a href="https://llvm.org/svn/llvm-project/lldb/trunk@204545" target="_blank">https://llvm.org/svn/llvm-project/lldb/trunk@204545</a><br>
</div><div><br></div><div>as it also touches ObjectFileELF.cpp and I somehow missed it yesterday...</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-23 19:28 GMT+01:00 Piotr Rak <span dir="ltr"><<a href="mailto:piotr.rak@gmail.com" target="_blank">piotr.rak@gmail.com</a>></span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Working on something else I've noticed that ProcessElfCore plugin can take considerable amount of time when once given big core file.</div>
<div><br></div><div>The file in question was 4.1 GiB core file generated by linux kernel, of process that crashed.</div>
<div><br></div><div>I took the small detour to investigate and it turned out to be spending ~72s</div><div>calculating crc32 for whole file from:</div><div><br></div><div>ProcessElfCore::CanDebug</div><div> ModuleList::GetShareModule</div>
<div><br></div><div>That in the result blocks ObjectFileELF::GetModuleSpecification.</div><div><br></div><div>That time was measured with Debug+Assert build variant, on puny i5 laptop with traditional HDD, thus in reality it would be bit better, but still meaningful.</div>
<div><br></div><div>If I understand correctly the main purpose of UUID's for ObjectFileELF is aiding gnu_debuglink which is used to locate debug info. The other one is related to ModuleSpec and ModuleList where it is used for identification.</div>
<div><br></div><div>First in case of modules doesn't make much sense, it won't be correct, or have even possibility to work, while second turns out to be useful, anyway. </div><div><br></div><div>Simple workaround or just inventing UUID for ModuleSpec before passing it to ModuleList::GetShareModule would probably work too for this particular case. ELF core files have no universal information reassembling gnu.debuglink or .note.gnu.build-id, thus we will be falling back to quite costly crc computation that is not strictly required.</div>
<div><br></div><div>I have not noticed also easy way to make this computation in background, so I decided limit it to PT_NOTE segments, which still have quite bit of unique info, like: combinations pids/tids/uids/register contexts, and sometimes much more.</div>
<div><br></div><div>That brings down time to somewhat more appealing value:</div><div><div>0.397 ms</div><div><br></div><div>Please note that while it was bit optimistic case for that solution, since it was single threaded process, and its PT_NOTE segment had only 4680 bytes. </div>
</div><div><br></div><div>For other core binary that had PT_NOTE segment of size ~48MiB it still takes:</div><div>1.206 s </div><div><br></div><div>in same setup.</div><div>That was pretty artificial case of *fork bomb* with almost 30k (29357) threads.</div>
<div><br></div><div>While using only note segment makes hitting collision it bit more likely, I think it is pretty remote, and not meaningful in practice.</div><div><br></div><div>Also if anyone has ideas about other/better solution to this problem I will gladly look into it, as performance of core file handling is important for my use-cases.</div>
<div><br></div><div>If this solution is fine for trunk, please commit, I don't have commit access.<br></div><div>Both raw diff and git path of same change are attached.</div><div><br></div><div>Cheers,</div><div>/Piotr</div>
</div>
</blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>