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