binaryninja-api
binaryninja-api copied to clipboard
Vector35
Purging snapshots/undo history in a large BNDB can take an inordinate amount of time
Version and Platform (required):
- Binary Ninja Version: 3.1.3522-dev
- OS: Windows
- OS Version: 10.0.25136.1000
- CPU Architecture: x64
Bug Description: I have a BNDB I've been working on for a ~52 MB Windows x64 executable. In the early days, the BNDB sat around ~5 GB. Over time, it has grown to ~23 GB. I figured it was probably about time I purged the snapshots and undo history to cut down on the size.
I fully expected this to take a few hours given the huge size of this thing, but after 12 hours, I started to suspect that BN was stuck. I checked the BNDB journal file being created and noticed it was still increasing in size by ~2 MB every 5 minutes or so (now sitting around ~294 MB), so there seems to be progress at least.
The process hasn't finished yet, but even at this stage, it seems to me that there might be some room for optimization.
Steps To Reproduce: I don't know if there's an easy way to reproduce this, short of me somehow sending over a BNDB when it gets to this kind of size.
Expected Behavior: I expected the process to take a few hours, but not quite this long.
I'm glad the feature ultimately worked for you. Yeah it seems like there's probably a ton of room for improvement there.
I'm also curious if future pruning is significantly quicker (it should be). And do you know which version of BN this database was first made in?
I'm also curious if future pruning is significantly quicker (it should be).
Yes, I did prune it once before it got to this huge size, and that didn't take anywhere near as long. Unfortunately, I don't remember the exact size/time for that run as it was a while ago.
Pruning the BNDB now at ~450 MB took less than 30 seconds to bring it to ~355 MB.
And do you know which version of BN this database was first made in?
Not exactly, but I started using BN a week-ish before 3.1 was released, and I was using dev builds from day one.