experiments: add a unix-socket idalib worker as the 3rd bench column

Adds UnixWorkerBackend (Option C): the same DirectBackend, but in a child
process that opens idalib on ITS main thread and serves one client serially over
an AF_UNIX socket with length-prefixed pickle (bytes ride raw — no hex, no JSON).
bench() is now generic over {direct, unix, mcp}; --worker runs the child.

3-way result (echo, us/call):

  op                 direct    unix       mcp     unix-vs-mcp
  resolve             1.4      42.9      4809       112x
  read_bytes(16)      0.8      78.6      4450        57x
  read_bytes(4096)  117.1     144.4      6312        44x
  disasm_line         2.9      81.2      5423        67x
  xrefs_to           40.6      77.9      4770        61x
  decompile(cached)  2907      2712     47456        18x

Takeaways:
* A lean local IPC round-trip is ~40-80us — ~60-110x cheaper than the mcp
  HTTP/JSON path (~5ms/call floor), while KEEPING crash isolation and the
  main-thread decoupling (the freeze/segfault costs of full in-process).
* Bulk bytes are the tell: read_bytes(4096) is 144us unix vs 117us direct (1.2x
  overhead) but 6.3ms over mcp — pickle ships 4096 raw bytes; mcp hex-encodes +
  JSON-wraps them. The hex view would feel instant on unix.
* ~50us/call = ~20k calls/sec vs mcp's ~200/sec: most of idatui's prefetch/
  paging/caching machinery exists to hide the 5ms; on a unix worker you'd barely
  need it.

Conclusion this run supports: the sweet spot is Option C (own thin worker), not
full in-process — you capture ~99% of the practical latency win without the UI
freeze during analysis or the loss of crash isolation.

0 files changed, 0 insertions, 0 deletions