[SharedCache] Optimize ReadExportNode #6322
Open
+88
−71
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ReadExportNode
is called frequently during the initial load of the shared cache and impacts how long it takes for parts of the shared cache UI to be functional. This is a collection of optimizations that cut the time spent withinReadExportNode
by 50%:Pass iterators to
ReadExportNode
rather than aDataBuffer
+ offset. The lack of inlining inDataBuffer
'soperator[]
kills performance. Ideally this would have usedstd::span
, but that would require bumping the minimum C++ version to C++20.Add
MMappedFileAccessor::ReadSpan
so thatReadExportNode
can operate directly on the mapped data without first copying it.Removes a call to
GetAnalysisFunctionsForAddress
whose result was unused.Use
std::find
to find the nul at the end of strings rather than assembling the string a character at a time. This avoids repeatedly growing the string.Avoid the usual
Symbol
constructor in favor ofBNCreateSymbol
. TheSymbol
constructor has over head in two forms:NameSpace
as an argument. Creating / destroying this allocates and deallocates memory We could create a single instance and reuse it for all calls, but...NameSpace
to the heap before callingBNCreateSymbol
and then deallocates them afterwards. This seems unnecessary, and adds a non-trivial amount of overhead.This can go back to directly constructing the
Symbol
once the constructors are improved.