Skip to content

Reduce renderer size and optimize everyday snippet performance - #686

Draft
hackjutsu wants to merge 2 commits into
masterfrom
codex/optimize-snippet-performance
Draft

hackjutsu wants to merge 2 commits into
masterfrom
codex/optimize-snippet-performance

Conversation

@hackjutsu

@hackjutsu hackjutsu commented Oct 29, 2026 •

Copy link
Copy Markdown
Owner

Ordinary snippet selection rebuilt and rerendered the entire sidebar and performed synchronous settings reads for every row. This change reuses sidebar metadata and unchanged rows, searches once per input change, and skips serialization of unchanged initial editor contents during typing. Content search retains only the highlights shown in its excerpt instead of constructing and retaining full-file highlight segments.

The dashboard and AsciiDoc converter load on demand. Unchanged snippet rendering is reused, redundant runtime assets and unused font formats are excluded, Babel targets Electron 42, and KaTeX uses the bundled stylesheet. CodeMirror remains eagerly available: an earlier lazy editor build delayed the first editor opening by roughly 316 ms in the local fixture, so it was removed. Large editors use a bounded viewport, and collapsed files release their renderer.

Measurements

Five alternating production-renderer runs on the same macOS machine, comparing this draft with original master using matching fixture data:

Workload Original master Draft
100-snippet browsing startup to visible UI 367 ms 284 ms
JavaScript work across 12 snippet switches 54.2 ms 11.9 ms
First editor opening 13.8 ms 12.8 ms
1,000-result search: two-token query to rendered update 100.5 ms 34.6 ms
1,000-result search: renderer heap after GC 30.0 MiB 18.9 MiB
1,000-result search: macOS process footprint 388.5 MiB 372.6 MiB

The search fixture contains 1,000 locally loaded snippets of 100 lines each; it does not measure network fetches. The macOS footprint is the system-reported aggregate for the main, GPU, network, and renderer processes, including GPU allocations. It is workload- and machine-dependent. In a separate five-run settled browsing snapshot, reported footprint was 241.5 → 232.0 MiB. The app-wide memory savings are modest and do not reach a 20–30% target.

These results do not imply that every operation is faster: the lazy dashboard and AsciiDoc converter are not covered by the first-use timing above. Reproducible profiling commands and fixture details are in tests/performance/README.md.

Validation

  • npm run lint — passed.
  • npm test — 436 tests across 66 files and development webpack build passed on the isolated draft branch.
  • Full Electron renderer smoke suite — passed, including snippet switching, paste search, keyboard selection, editor behavior, and existing fixture surfaces.
  • npm run test:packaged-smoke — production build, macOS arm64 packaging, and packaged rendering checks passed.
  • npm run build, then local npm start with the isolated everyday fixture — visibly rendered the sidebar and expanded, highlighted snippet. Checked dimensions, loaded fonts, and captured the screenshot below.
  • Live GitHub authentication, sync, and CRUD were not exercised; fixture checks cover rendering and the local interactions above.

Locally launched everyday snippet fixture

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant