Version and Platform (required):
- Binary Ninja Version: 4.3.6572-dev (37fd69ad)
- OS: macOS
- OS Version: 15.1
- CPU Architecture: M1
Bug Description:
There's a performance issue with BinaryView::AddUserSection where the more sections a BinaryView has the longer it takes to complete if the semantics for the section aren't DefaultSectionSemantics. In the case of DefaultSectionSemantics it appears this always takes less than a millisecond (faster than the resolution of time I was reporting). Outside of DefaultSectionSemantics it doesn't seem to matter what the size of the section is or what the semantics for it are, the time it takes for BinaryView::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 to BinaryView::AddUserSection is taking.
I'm then just running the following script I have in the snippet editor plugin:
import binaryninja.sharedcache
dsc = binaryninja.sharedcache.SharedCache(bv)
bv.set_analysis_hold(True)
for image in dsc.images:
dsc.load_image_with_install_name(image.name, True) # skip ObjC processingNOTE: 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 a memcpy 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.
Version and Platform (required):
Bug Description:
There's a performance issue with
BinaryView::AddUserSectionwhere the more sections aBinaryViewhas the longer it takes to complete if the semantics for the section aren'tDefaultSectionSemantics. In the case ofDefaultSectionSemanticsit appears this always takes less than a millisecond (faster than the resolution of time I was reporting). Outside ofDefaultSectionSemanticsit doesn't seem to matter what the size of the section is or what the semantics for it are, the time it takes forBinaryView::AddUserSectionto 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::AddUserSectionis 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_nameis 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::AddUserSectionbased on the number of sections in the binary view. Without seeing the code I'd suspect there's something like an array of non-DefaultSectionSemanticssections and each time a new section is added to that array its getting resized and requiring amemcpyto 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.