Large BNDBs result in unusably slow UI, 10+ second freezes

[yrp604]

Version and Platform (required):

• Binary Ninja Version: 6725
• OS: Windows
• OS Version: 11
• CPU Architecture: [e.g. x64 or M1]x64

Bug Description:
10+ second lag spikes when performing normal operations :(

Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

1. Click on a common type with a lot of xrefs
2. click somewhere else

Expected Behavior:
zoom zoom

Binary:
privately provided to v35

[galenbwill]

Define "large"?

[emesare]

This might be the same as what @WeiN76LQh described here #6301 (comment)

[WeiN76LQh]

Yes sounds exactly the same, clicking around on the linear view or types (and potentially other places) causing the xrefs UI to update seems to be still problematic when theres lots, like 10,000+, which is common in container types like DYLD Shared Cache. It seems a lock is causing the UI to freeze.

[fuzyll]

Peter has been working on this in the past week. Some of the performance impact is related to #6301, but not all. Part of the original report has been addressed, but there is still additional work to be done.

V35 employees can search for trash easel provided punctured to find the file.

[plafosse]

There has been significant progress on this and we will continue to make additional progress for this release. As of now its not perfect and if you select something that has millions of xrefs you'll likely still experience a brief hang, but it should no longer lock up the UI for minutes/hours