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