t3 code · performance audit continuation · 2026-10-09
where the time goes.
what the new code changes.
current matched comparison · web and built native electron
opening the current candidate
the cold web timeline
every marker starts at navigation. these are separate sample medians, with overlapping work; they are not a stacked causal waterfall.
native electron launch
24 package rows in the current startup graph
one source-map inventory per build of the observed pre-editor resources. generated UTF-8 segments are assigned to source packages; unmapped bytes remain separate. each package pair has its own scale. code bytes do not establish compressed size or CPU time.
current artifacts and native boundaries
earlier matched cpu and network measurements
this earlier batch compares baseline 454b94a13a with candidate 95a752a531 before subsequent input fixes. it is historical context. network emulation used 40 ms latency and 20/5 mbit/s throughput; CPU emulation used 4× slowdown. browser, viewport and cache workloads differ from the current comparison.
real provider and client checks
each timing is a single actual interaction. post-frame tasks are practical observation markers; they do not measure compositor presentation. provider response time includes backend, provider and network work.
unverified paths and observed errors
native mobile delta
earlier frozen source-server comparison · five starts per side
first config: 7.69 s → 5.63 s
the first configuration frame arrived 2.06 s earlier, a 26.8% reduction in the median. the listening-log median increased 0.8%, with overlapping ranges. most of the measured gain appears after the listener starts.
five fresh source processes per side, alternating pair order. isolated 481 mb state copied before every start; same baseline web assets; warm filesystem cache; shared linux host. authenticated websocket config and shell subscriptions, then serial settings reads until spawn + 10 s.
all milestones below use process spawn as zero. separate medians and overlapping work are aligned, not stacked.
settings RPCs during those first 10 seconds
candidate per-run maxima remained 236.5–283.7 ms; baseline maxima were 532.9–659.1 ms. this is a median of five per-run p90s. the baseline completed 25–29 probes per run; the candidate completed 42–47. unequal counts make this a startup-window observation rather than a fixed-size latency experiment.
requests arriving before the handlers attach
| probe | baseline | candidate |
|---|---|---|
| early page request, n = 5 | 0 answered; 2 timed out at 30 s; 3 closed at intentional shutdown | 5 returned http 200 |
| early unauthorized socket, n = 1 | 30 s handshake timeout | http 401 after real auth handler attached |
deferred maintenance and source-server limits
both long candidate observations recorded successful maintenance exits. the first and fifth pair had 40 s of extra idle observation; the middle pairs stopped before maintenance became eligible. the first candidate observation is shown below, in ms since process spawn.
maintenance waits for a served client and at least 10 s of activation, then starts one caller every 2 s. the 30 s no-client fallback and provider-probe timing require their own applicable verification. event-driven reactions remain immediate.
this candidate was frozen before later web fixes. it measures the combined source-server checkout at the named commit, not each optimization's isolated contribution. it does not measure a packaged SEA binary, electron launch, the live 58 gb installation, or native mobile.
fresh comparison · copied SQL harness · five processes per side
remove JSON scans from background queries
read-only node:sqlite fixtures; each query warmed once and timed once per fresh process; alternating pair order. equivalent 1,412 thread payloads and matching result counts, in about 2.4 gb of database data. each pair has its own scale.
the zero-row recovery result measures the cost of an empty scan. it does not establish recovery execution latency. scalar columns and indexes come from the integrated migration061 mechanism, 777b5e9a42; exact query checkout commits were not recorded.
fixture equivalence and migration limits
both fixtures contain the same 1,412 thread payloads, totaling 36,271,724 bytes, with a matching digest. the candidate fixture was prepared with migration061-equivalent columns and indexes while its migrations table remained at 60. the existing migration test is a separate correctness check.
returned string-length sums matched for every query and sample. the harness's size field counts non-string values as 8; it is not a serialized websocket byte count.
these copied SQL timings do not prove service or client integration. the one-time backfill on a large existing installation and the live 58 gb database remain unmeasured. old event data is not reclaimed by the candidate.
supplementary benchmark · provenance incomplete
fewer git subprocesses
five recorded samples per side. metadata detection uses 3 → 1 subprocesses; baseline checkpoint capture uses 10 → 9. the timing pairs below retain their measured ranges, but their JSON files do not record commits, repository workload, run order or host conditions.
these timings remain outside the final comparable headline until the missing provenance is supplied. they do not establish real-provider prompt or reply latency.
historical · 2026-10-09 · ec80933ac8 · recorded before 18:55 utc
opening a web client
navigation start → contenteditable composer present, in ms. five runs per row. unpinned browser; warm server; shared machine. this marker proves the editor exists, not that a provider can accept a prompt.
a warm new tab and a same-tab reload are different workloads. the reload retains renderer caches and opens the existing draft route.
the warm-tab milestones
all bars start at navigation. each marker is its own five-run median and range. overlapping work is not stacked or added.
all measured startup phases
phase medians do not add to the median total. some requests, parsing and rendering overlap.
the original stress runs
cpu-throttled runs: n = 5 each. network run: n = 4 successful samples; three stalled attempts were excluded. these runs pinned the browser to two cores and cannot be compared directly with the unpinned rows above.
server startup is a separate clock
spawn → milestone, ms; shipped nightly 0.0.46-nightly.20261007.2761; seeded 1.35 gb database, warm filesystem cache; server pinned to two cores; n = 5.
the historical 7,030 ms figure measured first config receipt. it did not measure electron launch, window visibility, or the whole desktop path.
historical · same original checkout
enter → a painted reply
new thread, claude haiku 5.5, one-word answer. ms since enter; unpinned client; n = 3. provider and network time vary separately from client work.
work surrounding that turn
the server and its git children still shared two pinned cores. checkpoint duration includes that constraint. the warm follow-up was one sample: assistant paint at 1,119.7 ms. it is context, not a comparable speedup.
historical · event time → observed state
settings, palette and terminal
unpinned browser. each row states the exact target, median [min–max] in ms and sample count. a next-paint event and content completion are different endpoints.
server settings still wait for confirmation. terminal prompt outliers reached 1,014.5 ms. the original investigation traced some terminal delays to background server work rather than the renderer.
typing under a steady cadence and a burst
keydown → task queued after a frame, ms/key. 200 characters × three repetitions = 600 sampled keys per row. the endpoint is not measured cpu time or compositor presentation.
event timing omits durations below 16 ms and rounds reported durations to 8 ms. its 16 ms floor cannot prove every physical keystroke took at least 16 ms.
scrolling the large bounded window
168 wheel events of 60 px per direction, across a 10,658 px window. three runs × two passes per mode. missed-frame share = inferred misses / (observed frames + inferred misses), estimated from animation-frame intervals at 60 hz. these are not compositor drop measurements. ranges span passes, not confidence intervals. the profiled tree builder spent 190 ms inside repeated locale comparisons; one collator now serves those comparisons.
historical · bytes and cpu are separate measurements
what the initial graph carried
largest source attribution
uncompressed bytes; one production build inventory.
startup cpu self time
ms; one cold-run profile, 100 µs sampling; two pinned cores.
these costs explain eager loading and repeated work. they do not show that a package is inherently slow. inclusive cpu times overlap; this chart uses self time.
the current candidate groups startup chunks and moves closed features out of the initial graph. its actual request and byte counts belong in the fresh comparison above.
mechanisms in the integrated candidate
source inspection confirms these changes. performance effect and runtime verification belong to the final comparison, not this list.
- desktop startup
- load the bundled renderer while the local backend starts. preserve the wsl-only splash and serialize main-window creation. native electron launch is measured above; packaged release startup is unmeasured.
- server activation
- park early http requests and socket upgrades until real handlers attach. start provider probes after the first config, then stagger maintenance after the startup quiet period. discover editors concurrently.
- web bootstrap
- overlap the initial matched-route chunks with authentication. reuse the initial environment descriptor in that app runtime. first pairing continues in place when no connection runtime exists; re-pairing still rebuilds the connection.
- asset delivery
- group boot dependencies by their entry points. generate a non-hidden build manifest and compressed sidecars. serve eligible hashed files with precompressed brotli or gzip. keep html refreshable.
- first-use features
- load the existing palette dialog, browser, diff, terminal, thread-details body, legacy sidebar and other closed surfaces when needed. move syntax and raw-html processing off the first module graph while keeping their original rendering paths.
- send path
- dispatch a plain foreground send before the dock and optimistic render. overlap claude process warm-up with the baseline checkpoint without offering the prompt before capture finishes. batch checkpoint metadata reads and release the thread lane before the post-turn vcs refresh.
- chat interaction
- reuse immutable document serialization, shortcut indexes, live media queries and changed-file trees. preserve stable palette rows. remember intentional end-follow, and stop held snapshots from overwriting scroll memory.
- terminal and theme
- download fonts and both wasm modules concurrently; compile streaming when the server provides a wasm mime type. resize the drawer directly during drag and commit its final height. read browser chrome colors after the theme paints. reveal expensive font previews as they enter the viewport.
- history and writes
- transport each checkpoint file list once for opted-in clients. record compact read-receipt and pull-request-link events. index sweep fields and reduce repeated trace metadata. existing database bytes are not reclaimed.
how opencode informed the pass
the transferable ideas were parallel renderer startup, deferring background work, reducing boot-module round trips, precompressed immutable assets and overlapping process warm-up with checkpoint capture.
the researched OpenCode v2 branch was d2905b8dd. v2.opencode.ai redirected to documentation; beta.opencode.ai was the hosted app. the inherited research points to renderer startup, checkpoint scheduling and compressed asset serving. their reported numbers were not reproduced on this machine and are not t3 speedup measurements.
persistent local service adoption is deferred. credential reuse, file-descriptor transfer and backend ownership across launches still need a coherent handoff path.
what still limits the result
- final data: the current web and built native electron results appear first. packaged release startup remains unmeasured. exact-head CPU/network stress is measured only when a corresponding current scenario row is present. earlier stress data uses 95a752a531.
- persistent service: deferred because credentials, file descriptors and backend ownership are tied to the current launch. parallel desktop loading does not provide a warm persistent backend.
- large live installation: the historical read-only sample was about 58 gb, with about 35 gb attributed to full-thread pull-request-sync events. synchronous sqlite blocked 2,224–5,864 ms/min across three trace windows. compact new events and indexed queries do not compact old rows or move sqlite into a worker.
- defaults and permissions: opening a draft still waits for authoritative project and server defaults. the speculative path that allowed sending before those defaults was dropped.
- expensive pages: pull-request rows and 543 license rows still mount through their existing paths. arbitrary row deferral and optimistic server-setting overlays were dropped because they changed behavior without adequate proof.
- rendering and connection modes: the client checks above identify what was observed and at which head. unlisted provider paths, remote and tunnel connections, native mobile, and desktop lifecycle remain unverified. web-width checks do not verify a native mobile app.
- provider boundary: the warm-up overlap is specific to claude. actual reply time still includes provider startup, model execution and outbound network latency.
corrections to the original report
| historical claim | correct interpretation now |
|---|---|
| “desktop open, 7.0 s” | server spawn → config response on the shipped nightly. electron was not measured. |
| “composer usable” | the original marker detected a contenteditable node. sending and provider completion require separate proof. |
| “medians of 5 runs” | sample counts vary: startup n = 5, network n = 4, unpinned sends n = 3, interactions often n = 3, cpu attribution n = 1. |
| stacked send phases | independent medians and overlapping work cannot form an exact causal waterfall. this report aligns milestone bars at the input event. |
| “140 visible threads” | 140 retained thread records in the seed. the chat audit found six top-level sidebar threads; subagent records were filtered. |
| “server never the bottleneck” | applied to specific warmed seeded startup responses. cold server startup and large-history reads were separately slow. |
| “all keys take at least 16 ms” | event timing's reporting floor cannot establish that bound for unreported keys. |
| old file:line references | belong to ec80933ac8. current code moved and gained lazy boundaries; line numbers are not current evidence. |
| preview summary says blocked | that markdown file is stale. the later preview data records a completed historical pass. neither proves today's candidate. |
| “hashed assets are no-cache” | a shipped-nightly observation. the fresh main baseline already has manifest-backed immutable handling; the candidate also fixes manifest packaging and adds compressed sidecars. |
| scroll “dropped-frame share” | the old percentages divide misses by observed frames. using misses / (observed + misses) gives 6.6–10.6% unpinned and 16.0–25.4% pinned. rAF timing only infers misses. |
| estimated time savings | hypotheses from the audit. do not add them together or present them as measured candidate gains. |
measurement boundaries
the historical audit used isolated state copies, production assets, http and websocket interception, browser observers, cpu profiles and server spans. its box was shared, with load averages roughly 2–20. the proxy added about 110 ms to socket handshakes in one rig comparison.
source artifacts are the original report and aggregate data under results/startup, results/server, results/chat, results/panels, results/bundle and results/preview. this continuation contains aggregate timings, byte counts, code mechanisms and checks against isolated benign state. it contains no private conversation history or pairing credentials. raw startup logs require separate QR and credential redaction before publication.
a final comparison needs the same browser, viewport, dataset, cache state, workload, measurement endpoint and server build on both sides. identify both commits, record load, show sample counts and ranges, and exercise the actual provider/client path.