SPEED.md: where the last 2ms goes, and why batching is not worth building

Measured so nobody re-derives it: HTTP is 0.165ms of the 2.0ms floor and
execute_sync marshalling onto IDA's main thread is the other 1.86ms, inside
IDA's own serve() loop. Call volume is already minimal (8 calls to scroll 2000
rows, 4 for a 1060-block graph), so a batch endpoint would save single-digit ms
on flows costing hundreds. The largest single operation in the app -- decompiling
a 17KB function -- is 10806ms here and 10723ms on the worker: pure Hex-Rays,
0.8% apart, no transport in it.

1 files changed, 30 insertions, 1 deletions

diff --git a/.fastfeedback/SPEED.md b/.fastfeedback/SPEED.md
index f5b1f84..e402ea1 100644
--- a/.fastfeedback/SPEED.md
+++ b/.fastfeedback/SPEED.md
@@ -164,7 +164,36 @@ that returns itself, i.e. LINE tracing in every frame, which made
 `ida_bytes.get_flags` 52x slower than native. The snippet detaches it and
 restores it in a finally; `IDATUI_CODEMODE_TRACE=1` keeps the stock behaviour.
 
-**What is left is the 2ms round-trip floor.** A trivial op (`data_type`,
+**What is left is the 2ms round-trip floor, and it is NOT ours.** Measured against
+the same worker, same connection:
+
+| | cost | whose |
+|---|---|---|
+| `GET /health` (no execute_sync) | 0.165ms | HTTP transport |
+| `execute_python("result = 1")` | 2.025ms | + `ida_kernwin.execute_sync` |
+
+So HTTP is 7% of the floor and marshalling an operation onto IDA's main thread is
+92%. The worker runs IDA's own `kernwin.serve()` dispatch loop, so that latency is
+inside IDA, not something Code Mode exposes a knob for.
+
+**Do not re-chase this by batching operations.** The call volume is already
+minimal, measured on `targets/bash`:
+
+| flow | wall | calls |
+|---|---|---|
+| open a listing | 3.2ms | 1 |
+| scroll 2000 rows | 87.9ms | 8 |
+| rename + re-render those rows | 36.2ms | 4 |
+| graph of a **1060-block** function | 171.0ms | 4 |
+| decompile a 17785-byte function | 10806ms | 1 |
+
+Block-coalescing, the page digest and the prefetch caches already collapse the
+bursts, so a batch endpoint would save single-digit milliseconds on flows that
+cost hundreds. And the big number is pure Hex-Rays: that same decompile is
+10723ms on the worker backend (0.8% apart) — there is no transport in it at all.
+
+
+_Superseded note:_ **What is left is the 2ms round-trip floor.** A trivial op (`data_type`,
 `force_recompile`, one xref query) is ~2.5ms wall clock and looks like 40x
 against an in-process worker. That is fixed by making FEWER calls, not faster
 ones — which is what the digest/`expect` path does for the listing.