Skip to content

Improve vault performance and tab overflow - #37

Merged
adibhanna merged 3 commits into
mainfrom
codex/tab-strip-overflow
May 8, 2026
Merged

adibhanna merged 3 commits into
mainfrom
codex/tab-strip-overflow

Conversation

@adibhanna

Copy link
Copy Markdown
Contributor

Summary

  • improve large-vault/runtime behavior with progressive loading, note prefetch/search helpers, metadata parsing coverage, and performance tooling
  • lazy-load heavier preview surfaces and centralize prompt/confirm request flows
  • fix workspace tab overflow behavior with dynamic scrollbar spacing and a persisted wrap-tabs setting

Validation

  • npm run typecheck
  • npm run test:run

@adibhanna adibhanna changed the title [codex] Improve vault performance and tab overflow Improve vault performance and tab overflow May 8, 2026
@adibhanna
adibhanna marked this pull request as ready for review May 8, 2026 17:21
@adibhanna
adibhanna merged commit 39c4abd into main May 8, 2026
5 checks passed
@adibhanna
adibhanna deleted the codex/tab-strip-overflow branch May 8, 2026 17:21
MichaelC001 pushed a commit to MichaelC001/zennotes that referenced this pull request Oct 21, 2026
…t instead

ZEN_PERF_ENFORCE=1 failed every run of perf:desktop-runtime on the
deferred-chunk check, because vendor-markdown and vendor-highlight load
in the normal flow. That was already true of 2.71.0; ENFORCE being off
was the only reason its run passed.

The list is from ZenNotes#37, when markdown rendering belonged to Preview. Since
then the live preview took the stack into the editor: table cells render
through renderMarkdown (cm-table's renderInlineCell, 2.4.0, kept on the
reading view's parser on purpose by ZenNotes#559), so do comment bodies in
CommentsPanel, and formulas render through KaTeX (cm-math-render,
cm-latex-completions), all synchronously in a widget's toDOM or a render.
KaTeX lives in vendor-markdown, which statically imports vendor-highlight
through lowlight, so each of the four puts both chunks in the Editor
chunk's static graph. App also warms the Editor module during boot
(workspace.ready waits for it), so the stack arrives before any note is
open, by design.

Deferring it would paint raw source for a frame on the first table,
formula or comment of a session. Stubbing the four imports out in a
throwaway build bought 5 to 9 ms on the first note open and 1.3 MB of
heap, and nothing on boot or note switches. The check was wrong, not the
app.

The two chunks leave the normal-flow list and get the check that still
means something: they must not be fetched before App's first render.
Anything that early is in the entry's static graph, ahead of first paint,
which is the failure e7a9879 fixed (a manualChunks rule hoisted mermaid
into the entry and vendor-markdown came with it). The renderer loads over
file://, which Resource Timing never records, so the window is timed from
each CDP request's wallTime against the page's timeOrigin and the
renderer.app.mounted sample. The report prints the chunks fetched before
mount.

When that timing cannot be taken (no renderer.app.mounted sample, as in
an older ZEN_PERF_DESKTOP_APP_PATH build, or the entry chunk outside the
window, which means the two clocks disagree), the report says
"unavailable", and under ZEN_PERF_ENFORCE the run fails and says which
of the two it was. A guard that quietly cannot run would pass exactly the
regression it is there to catch.

No app change. On the 764c10d build, interleaved: the old harness exits
1 in 4 of 4 runs, the new one exits 0 in 4 of 4 with the same numbers
(ready-to-show 205 ms, workspace ready 531 ms, first note open 110 ms,
switch p50 33.6 ms), and the before-mount list is exactly the entry's
static closure (index, vendor-react, app-store, vendor-editor,
app-wikilinks). A build importing renderMarkdown from main.tsx fails the
new check with both chunks named, and a copy of the harness forced into
the unavailable case exits 1 under ENFORCE and 0 without it. The final
harness passes ENFORCE on a fresh build. typecheck 8/8, app-core 3,308
tests, desktop 1,183 tests.
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