Notable perf regression on continuous single step on macOS due to memory region pulling

[xusheng6]

I cant tell when it started to happen, but I noticed that if I simply press and hold F7, the single step is observably slower than stable 5.3

We should 1) investigate the root cause of the slow down, 2) set up a test for the single step performance

[UvuvDev]

Disabling the following setting:

Speeds up performance to expected amounts. Most likely the performance slowdown is from mishandling the cache of memory segments.

[UvuvDev]

97% of samples (7259/7489) from a test binary are inside one call chain:

DebuggerController::SyncMemoryRegions()
  - GetMemoryMap() -> DebuggerMemoryMap::Update()
    - LldbAdapter::GetMemoryMap()   [lldbadapter.cpp:1657, m_process.GetMemoryRegions()]
      - lldb::SBProcess::GetMemoryRegions()
        - Process::GetMemoryRegionInfo()   - called ONCE PER REGION, in a loop
          - GDBRemoteCommunicationClient::GetMemoryRegionInfo() - ask about a specific memory region 
            - SendPacketAndWaitForResponse()  - full blocking socket round trip per region

So every time we want to get the memory regions in order to determine their changes, we are requesting every single region's info (150 for this example), which is taking up the significant majority of the time spent between each step. There is a few possible solutions here we've come up with:

1. Patch LLDB to add something like a GetBulkMemoryRegionInfo(), so it returns the memory regions in bulk at once.
2. Have a layer so we can use things like /proc/PID/maps on linux or vmmap on macOS to directly parse the memory region inside Binary Ninja, bypassing LLDB altogether
3. Disable this setting by default.

[xusheng6]

97% of samples (7259/7489) from a test binary are inside one call chain:

DebuggerController::SyncMemoryRegions()
  - GetMemoryMap() -> DebuggerMemoryMap::Update()
    - LldbAdapter::GetMemoryMap()   [lldbadapter.cpp:1657, m_process.GetMemoryRegions()]
      - lldb::SBProcess::GetMemoryRegions()
        - Process::GetMemoryRegionInfo()   - called ONCE PER REGION, in a loop
          - GDBRemoteCommunicationClient::GetMemoryRegionInfo() - ask about a specific memory region 
            - SendPacketAndWaitForResponse()  - full blocking socket round trip per region

So every time we want to get the memory regions in order to determine their changes, we are requesting every single region's info (150 for this example), which is taking up the significant majority of the time spent between each step. There is a few possible solutions here we've come up with:

1. Patch LLDB to add something like a GetBulkMemoryRegionInfo(), so it returns the memory regions in bulk at once.

2. Have a layer so we can use things like /proc/PID/maps on linux or vmmap on macOS to directly parse the memory region inside Binary Ninja, bypassing LLDB altogether

3. Disable this setting by default.

To add some context to this, even when we are doing local debugging with LLDB, we are still doing remote debugging on the local host, so the same latency issue with remote debugging also affects us, and accumulates when it is getting a lot of things going on

[xusheng6]

Update on the root cause: it is not a round trip per region. A single qMemoryRegionInfo is ~15-30 µs. The cost is macOS debugserver collecting the dirty page list for every region, page by page (get_dirty_pages() -> mach_vm_page_range_query(), both present in the debugserver we ship), so reply latency is proportional to the region's size, not the region count.

Measured on arm64 macOS with our lldb 22.1.8, trivial test target, 71 mapped regions:

per stop
full SBProcess::GetMemoryRegions()	139-152 ms
one StepInstruction	1.7 ms
comparing the new region list against the previous one	0.0018 ms
map actually changed while stepping	0 of 40 steps (compute loop), 0 of 60 (malloc loop)

So the comparison/rebuild logic in SyncMemoryRegions() is not involved — it never even rebuilds while stepping. It is all collection. Evidence that size, not count, drives it:

• 1.6 GB r-x dyld shared cache region: 27 ms, and the reply is dirty-pages:; — empty, i.e. ~100k pages scanned for nothing
• 16 KB region: 0.013 ms
• 2 GB single untouched anon mmap: 1.69 ms per reported 128 MB chunk (~0.2 µs/page) — so it is not entry count
• same 128 MB region after dirtying every page: 8192 dirty pages, 81,980-byte reply

We can't simply stop emitting the dirty list: Process::SaveCore calls the same Process::GetMemoryRegions() and uses it for --style=modified-memory / stack-only cores (Process.cpp:7019), and memory region prints it.

Proposed fix: add a custom bulk packet to debugserver that returns all mapped regions in one reply without dirty pages, advertise it in the feature list, and consume it from a new code path (new Process/SB entry point) so the existing qMemoryRegionInfo stays untouched for save-core. Being bulk also skips the unmapped-hole walk, which is a separate cost (one 384 GB hole alone is 43 ms). Expected: ~139 ms -> a few ms. Stock/Xcode debugserver and remote targets fall back to today's per-region path.

Two follow-ups regardless of that fix:

• DebuggerState::MarkDirty() invalidates the memory map on every stop even though it demonstrably doesn't change while stepping — worth making the invalidation event-driven.
• DebugMemoryMapWidget::updateContent() (ui/memorymapwidget.cpp:407) pulls the map on every stop with no visibility check, independent of the debugger.useMemoryMapSegments setting.

Linux (lldb-server) has a different implementation and still needs to be measured separately.

[xusheng6]

We will wish to reevaluate #500 in light of the series of issues I ran into and the rise of AI coding