Clarifying (faster) for README.md install section #529

Activity

1. 21sagge commented on Aug 5, 2026

   

   21sagge

   on Aug 5, 2026

   More actions

   Data point for the (faster) question, from a Windows box where the difference is not subtle.

   All three rows below run the same ccstatusline 2.2.27 against the same stdin payload, medians of 5-6 runs, warm npm cache, Windows 11, Node 22 via nvm4w. Process spawns are expensive on this machine (endpoint security software inspects each one), which scales the absolute numbers up but not the ratios:

   statusLine.command	median
   npx -y ccstatusline@latest	9865 ms
   ccstatusline (npm global shim, what "Pinned global install" writes)	1156 ms
   node <prefix>/node_modules/ccstatusline/dist/ccstatusline.js	1054 ms

   So on Windows the answer to "faster in what sense?" is startup, and it dominates everything else: ~8.5 s of the npx row is registry resolution for @latest plus the extra npm parent process, before node even starts loading the bundle. The global shim vs. direct-node delta is only ~100 ms, so the shim is fine; it is npx/bunx specifically that costs.

   Widget configuration barely moves the needle, which surprised me: full config 1236 ms vs. a single model widget 1471 ms (noise-level difference). The cost is process startup, not the work.

   Where it stops being a startup-latency footnote and becomes a machine-load problem: Claude Code refreshes the status line event-driven, debounced at 300 ms, in addition to refreshInterval. When one invocation takes ~10 s and refreshes are requested every ~2 s, invocations overlap instead of queueing. I caught 5 concurrent processes from a single session:

   44248  11:21:33  node .../npx-cli.js -y ccstatusline@latest
   38960  11:21:35  node .../npx-cli.js -y ccstatusline@latest
   43428  11:21:37  node .../npx-cli.js -y ccstatusline@latest
   43828  11:21:40  cmd /c ccstatusline
   11324  11:21:41  node .../_npx/<hash>/.../ccstatusline.js
   

   That is the same failure mode as #22 and #103, and it is still what a new user gets by following the README, because the npx form is presented first and framed as a feature ("Easy Installation - Install directly with npx or bunx - no global package needed"), while the pinned install is documented further down.

   Suggestion for the README section this issue is about: replace the bare (faster) with what is actually faster, and say it in per-invocation terms rather than install terms, e.g. "Bun/global install start faster per render; npx -y ...@latest re-resolves the version from the npm registry on every single status line refresh". A one-line note that the status line runs on every refresh, not once per session, would probably prevent most of these reports on its own, since the npx cost is invisible if you assume it runs once.

   Happy to open a separate issue for the Windows numbers if you'd rather keep this one purely about README wording.
2. sirmalloc

   closed this as completedin #714on Oct 29, 2026