Performance: measured wins across boot, broadcast path, and client bundle

[ishu86]

Performance pass across boot, the sidebar broadcast path, and the client bundle. Every number below is measured on this machine, not estimated — commands and methodology in each commit body.

Results

Metric	Before	After
Entry chunk	2,180 KB / 626 KB gzip	1,183 KB / 356 KB gzip (−43%)
Cold start (median, warm cache)	518 ms	~270 ms
Sidebar re-derives per streaming turn	1 per transcript entry	1 per 15s activity bucket
Tests	1730 pass	1732 pass (+2 new, covering the sidebar-bump change)

What's here

• Boot: pi SDK now loads on first use instead of at every startup (measured 170ms import cost for a provider most users never touch); the startup update-check fetch is bounded at 5s instead of unbounded.
• Send latency: chat.send no longer reads the entire payload sidecar just to check if a chat is empty (3ms → 45ms depending on chat size, now skipped almost always).
• Sidebar broadcast: stateVersion was bumped on every appended transcript entry, forcing a full sidebar re-derive + whole-snapshot stringify per entry — even though the dedupe signature discarded almost all of it as unchanged bytes. Now bumps only when an entry actually moves something the sidebar shows.
• Git broadcast: a git command triggered an unfiltered broadcast to every socket, including a full terminal snapshot (the serializer walks the whole scrollback — measured 3.7–14.9ms and 72–347KB depending on scrollback size), paid every 5s while the diff panel polls. Scoped to just the affected project + sidebar, matching every other broadcast call site in the file.
• Command resolution: resolveCommandPath always spawned a synchronous login shell (~5ms, up to 24ms observed); Bun.which now covers the common case first (~0.045ms), with the login shell staying as fallback for PATH entries only it can see.
• Client bundle: GitPanel, TerminalWorkspace, BrowserPanel and SettingsPage were statically imported into the entry chunk despite being sidebar panels or a separate route. GitPanel alone pulls @pierre/diffs → shiki → ~300 language grammar chunks. Code-split all four.
• Re-renders: the transcript's per-row wrapper wasn't memoized, so every streamed entry walked all N visible rows through three component invocations before React's inner memo could bail. Extracted and memoized it.

Known trade-offs

• Scoped git broadcast: two projects pointing at the same repo (e.g. a monorepo opened as separate projects at different subpaths), or the local-projects "last modified" timestamp, now update on the next 5s poll instead of instantly. Self-healing, low-frequency edge case.
• Terminal dispose is now a dynamic import: disposeCachedTerminal moved behind import() so the 500KB xterm bundle isn't pinned into the entry chunk by one cleanup helper. This lands a microtask later than before; only matters if a new terminal reused the exact same id in that window, which doesn't happen since ids are freshly generated.

Verification

• bun test: 1732 pass, 0 fail (baseline was 1730; +2 new tests locking the sidebar-bump semantics — verified they fail without the fix)
• bun run check: typecheck + both production builds clean
• Cold-start and broadcast-cost numbers measured directly against this repo's dependencies (real @xterm/headless serialization, real EventStore), not estimated

[greptile-apps]

Confidence Score: 4/5

The PR should not merge until the startup timeout is separated from interactive package-update lookups.

Findings

1.  Timeout Breaks Interactive Updates ▶

Summary

• Lazily loads settings, terminal, browser, Git, and Pi SDK module graphs.
• Limits sidebar derivation to changes represented in its read model and scopes Git-command broadcasts.
• Adds a fast command-path lookup and memoizes transcript/setup components.
• Introduces a five-second npm lookup timeout, but currently applies it to interactive update operations as well as startup.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Boot[Server boot] --> Update[Package version lookup]
  Boot --> Provider[Provider selected]
  Provider --> Pi[Lazy-load Pi SDK]
  UI[Client entry] --> Route{Opened surface}
  Route --> Settings[Lazy settings chunk]
  Route --> Terminal[Lazy terminal chunk]
  Route --> SidePanel[Lazy Git or browser chunk]
  Stream[Transcript append] --> Signature[Sidebar-visible signature]
  Signature -->|Changed| Sidebar[Re-derive sidebar]
  Signature -->|Unchanged| Skip[Reuse sidebar snapshot]
  GitCommand[Git command] --> ProjectGit[Refresh affected project]
  GitCommand --> Sidebar

Loading

_{Reviews (1) · Last reviewed commit: "Code-split GitPanel, TerminalWorkspace, ..."}

[greptile-apps]

Timeout Breaks Interactive Updates

The five-second timeout is applied inside the shared package-version lookup, not only during startup. The interactive stable-reinstall path also calls this helper, so if the npm registry takes more than five seconds to respond, an explicit reinstall is aborted and reported as “Update failed” even though the request could have succeeded. Make the timeout startup-specific or allow interactive callers to choose a longer limit.

Knowledge Base Used: Settings, updates, and usage controls