perf(app): the backend listens before it announces its port — a launch stops paying half a second

[brcampidelli]

What

The desktop backend listen()s on its socket before it writes the port file the Tauri shell waits on. One line in _bind_app_socket; a launch stops paying ~0.5 s on Windows (and one 150 ms retry elsewhere) for a connection that met a bound socket nobody was listening on yet. Item 8 of the list audited on 2026-09-16 ("Speed") — measured first, then the one fix the registered rule allowed.

The measurement (bench/startup, registered before it ran, US$ 0)

Our own numbers, on this machine (i7 laptop, Windows 11, repo venv) — the marketing figures on the audited list were never ours and are not cited:

what	before	after
spawn → socket bound (port file written), warm median	1.02 s	1.01 s
bound → /api/health answers	0.53 s	0.02 s
spawn → health, warm median	1.55 s	1.03 s (−34%)
imports at boot, summed	0.90 s	—
harness overhead per turn (instant agent, 20 turns)	16.4 ms median	15.0 ms
idle CPU over 10 s / RSS after boot	0.0 s / 91 MB	same

Predictions vs numbers, published as registered: cold start inside the 1.5–4 s range but the named culprit was wrong — litellm is not imported at boot at all (already lazy); the boot is imports (0.90 of 1.02 s) spread over chimera.cli.main 454 ms, httpcore 131, fastapi 123, code_api 93, with nothing above 15%. Turn overhead predicted 30–150 ms, measured 16 ms. Idle held.

Where the half second went

Not the server: its event loop was idle 10 ms after the port file was written (stack-sampled), and a request sent 1.5 s after the bind was answered in 12 ms. It was the client's connect. _bind_app_socket bound the socket and left listen() to uvicorn; the port file — the shell's discovery channel — was written in between; and on Windows a SYN to a bound-but-not-listening socket is dropped, not refused, so the shell's first connect_timeout(500 ms) sat on the 500 ms SYN retransmit timer on every launch. On POSIX the SYN is refused and wait_for_listening sleeps 150 ms and retries. bench/startup/probe_connect.py is the diagnostic that found it: a raw-socket client inside the app's own boot — connect() 0.51 s, request 6 ms.

Not changed, by the rule

The registration said only a deferral or cache that changes no turn's behaviour, and only for an item above 20% of its total. Imports: keyring (48 ms) loads the credential vault the first turn needs; importlib.metadata (71 ms) is imported by pydantic-settings regardless, so a lazy __version__ saves nothing. The shell's 200 ms port-file poll (~100 ms average) is a 7–10% item — noted for the Rust side, not touched here. The packaged sidecar was not measured; the port-file sequence is the same code, so the fix applies to it identically.

Tests

test_the_app_socket_listens_before_the_port_is_announced: a connect to the returned socket succeeds within 400 ms with no server accepting (the kernel completes the handshake from the backlog). Sabotage: listen() removed → the test fails on Windows (2 s timeout; on POSIX it would be refused); restored. Full gate on a clean copy in WSL: ruff clean, mypy clean (360 files), 6530 passed, 18 skipped, 10 xfailed in 184 s.

🤖 Generated with Claude Code