Measured initialization bounds do not support the proposed snapshot overlap as a useful optimization in these fixtures. No code was changed, and no startup gain is claimed. This does not establish that desktop startup has no other optimization opportunities.
Original and current head: 6417151c093e54dbba0e6c824c69d03983793b9a. Scope: Electron app initialization, snapshot and primary backend startup. Parent plan.
Seven serialized unprofiled launches place legacy storage, snapshot initialization and configured-port selection together inside 5–12 ms. App-ready to backend-start spans 25–41 ms, including necessary work. These are elapsed log intervals, not recoverable CPU time or projected gains.
Chart: app-ready to backend-start. Baseline only. No candidate or before/after comparison exists.
All values in milliseconds. IPC→port includes legacy storage and snapshot. Returning absolute timings may include stale-singleton recovery and are not comparative evidence.
| Fixture | Run | IPC→port | Ready→spawn | Visible window | Command-ready | Usable |
|---|---|---|---|---|---|---|
| returning | 1 | 12 | 41 | 742.25 | 1665.68 | 2557.53 |
| returning | 2 | 7 | 35 | 853.71 | 1564.39 | 2461.84 |
| returning | 3 | 5 | 26 | 441.94 | 1229.55 | 2081.35 |
| returning | 4 | 7 | 29 | 516.15 | 1175.26 | 2074.64 |
| fresh | 1 | 6 | 25 | 724.15 | 2163.97 | 3595.01 |
| fresh | 2 | 11 | 40 | 1031.02 | 3229.63 | 4491.62 |
| fresh | 3 | 8 | 31 | 746.95 | 2542.16 | 3738.15 |
Boat bx_2w758bmb, Ubuntu 24.04 x64 VM, default 4 vCPU / 8 GB. Production Linux unpacked directory; Electron 44.10.1; Node 26.12.1 and pnpm 12.14.0. Original artifact unchanged. Snapshot disk warmed by preceding runs; no page-cache drop or cold-cache claim. Fresh homes empty; returning fixture has 12 synthetic projects and 48 stopped threads with prewarmed Chromium cache. No real credentials or conversations copied.
Window means X11-visible window. Command-ready means HTTP descriptor 200 behind startup.awaitCommandReady, distinct from listening. Usable means actionable fresh onboarding, or a returning composer accepting and clearing synthetic text. Every launch restores its own home. Updates disabled; flags --no-sandbox --password-store=basic --remote-debugging-port=<iteration-port> --user-data-dir=<isolated>. Harness owns spawned process cleanup.
Three fresh samples are unaffected by fixture singleton symlinks. Four returning launches completed, but their absolute timings may include lock recovery. Latest harness excludes SingletonLock, SingletonCookie and SingletonSocket without following symlinks. Initial overlapping warmup/profile diagnostics are excluded. Small samples establish narrow bounds, not stable medians/p95, gain acceptance, recovery behavior or native Windows/macOS timings. No 20-pair experiment was run because there is no candidate.
One retained main-process diagnostic, sampled at 1000 microseconds, spans 439.59 ms from before boot to observed backend-start. Clerk setupOAuthTransportIpcHandlers receives 108.19 ms self attribution; CommonJS wrapSafe 84.86 ms and compileFunctionForCJSLoader 14.85 ms. Native samples can reflect synchronous I/O or subprocess waiting. These magnitudes are diagnostic, not unprofiled timing acceptance. An earlier 100-microsecond profile produced inconsistent magnitudes and is excluded.
Clerk bridge creation couples default-protocol registration to required privileged-scheme and OAuth IPC setup. No supported selective suppression was established. Moving it across readiness risks single-instance, userData and early deep-link behavior. Compilation/loading is adjacent to separate compile-cache/build ownership. Neither observation establishes a safe implementation with demonstrated benefit.
R=<isolated benchmark root> export PATH="$R/source/node_modules/.bin:$R/toolchain/node-v26.12.1-linux-x64/bin:$R/toolchain/pnpm/node_modules/.bin:$PATH" node scripts/build-desktop-artifact.ts --platform linux --target dir --arch x64 --output-dir "$R/artifact-original" --verbose xvfb-run -a -s '-screen 0 1280x900x24' node "$R/bench.mjs" "$R/artifact-original/linux-unpacked/t3code" "$R/source" "$R/UNIQUE" fresh 3 # Returning: unpack synthetic fixture into UNIQUE/fixtures first, then use returning 4. # A new output root is required for each invocation.
Binary SHA256: 7722b3b95b0a31e24906f8046c1bf29cb03c1b99f67058b0b9a4c0e8681c0d87
app.asar SHA256: 75aab08523d3a1f3d5752d8414d2ccfa7595942c86dbcb8ff26a08ecae0d4e98
Returning fixture SHA256: b04725503fd8e5fa8a4744342185b35bf67907ece8ab65cce8d66b8362223d34
DesktopApp.ts:326/341 configures identity twice; phases need explicit ownership before deleting either call. DesktopBackendPool.ts:162 and DesktopApp.ts:262 can both create a window, so earlier backend startup would require a gate at the window owner. DesktopApp.ts:194 serializes snapshot and backend work, but its measured headroom does not justify changing that lifecycle here.
No implementation means no trim, council, cubic, changed-file checks or PR. GPT 6.1 Sol investigated and built the measurement evidence through Codex in T3 Code. Independent proof audit: supported for the narrow no-code conclusion, no material evidence gap. Configured-port Ubuntu fixtures do not establish costs for sequential port scanning, legacy migration, WSL, other exposure modes, or native macOS/Windows. Fork retained for dispatcher cleanup; raw logs, profiles, commands and hashes retained in the evidence archive. PostPlan uses fallback black colors because the active host theme could not be read.