-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BinaryView::AddUserSection
gets increasingly slower for sections with semantics that aren't DefaultSectionSemantics
#6271
Labels
State: Awaiting Triage
Issue is waiting for more in-depth triage from a developer
Comments
For the first library loaded, which was
By the 67th, for the library
|
xusheng6
added
the
State: Awaiting Triage
Issue is waiting for more in-depth triage from a developer
label
Dec 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version and Platform (required):
Bug Description:
There's a performance issue with
BinaryView::AddUserSection
where the more sections aBinaryView
has the longer it takes to complete if the semantics for the section aren'tDefaultSectionSemantics
. In the case ofDefaultSectionSemantics
it appears this always takes less than a millisecond (faster than the resolution of time I was reporting). Outside ofDefaultSectionSemantics
it doesn't seem to matter what the size of the section is or what the semantics for it are, the time it takes forBinaryView::AddUserSection
to complete will be roughly the same and gradually increase as more sections are added.Steps To Reproduce:
I'm using a modified version of the DSC plugin, which is roughly the same as this PR and then I'm using
std::chrono::high_resolution_clock::now()
to time how long this call toBinaryView::AddUserSection
is taking.I'm then just running the following script I have in the snippet editor plugin:
NOTE: the extra argument to
load_image_with_install_name
is to skip Objective-C processing which is added with this PR that has not currently been merged.The script pauses analysis and then just loads all images in the DSC one by one.
Expected Behavior:
It seems to me that this is an unnecessary performance issue. As in its likely that whatever is causing the slow down could be avoided with some optimisation. It would not surprise me if whats going on here is there's a data copy occurring each time
BinaryView::AddUserSection
based on the number of sections in the binary view. Without seeing the code I'd suspect there's something like an array of non-DefaultSectionSemantics
sections and each time a new section is added to that array its getting resized and requiring amemcpy
to move the data from the old array to the new one.Binary:
I was testing on an iOS DSC extracted from iOS 18.1.1, it shouldn't matter exactly which.
The text was updated successfully, but these errors were encountered: