[performance] A fair comparision with obsidian

[SandeepKumarKuanar]

Performance: ZenNotes feels heavier than Obsidian

Observation: Scrolling through long notes (500+ lines or 48k characters) has noticeable lag compared to Obsidian, the images which are not in view always gets re-rendered when comes in the view which create a janky experience. The UI feels slightly less responsive during rendering. This is completely fair given to the AI assisted coding and fast production of this app. Comparison with Obsidian might actually feel unfair as Obsidian got time to optimized for years and then ZenNotes came around April of this year.

Potential causes:

• React re-renders on every keystroke
• Unoptimized Markdown parsing/rendering
• Heavy DOM updates during scroll

Suggestion: Would it be helpful to profile the app and identify bottlenecks? I'd be happy to help test if this gets prioritized.

[adibhanna]

Thanks for this, and for the fair framing. I profiled it rather than guessing, and built a harness that drives the real desktop build: an 815 line / 126k character note (bigger than your 48k) with ten 1600x1200 images, scrolled top to bottom and back, plus a fast flick pass and a typing burst. It lives in the repo now as npm run perf:editor-scroll so any future claim here can be checked against numbers.

Of your three suspects, one was exactly right and two did not reproduce for me.

Confirmed: images re-render when they come back into view. This was real and now fixed in e78ca27. CodeMirror throws away a widget's DOM when it scrolls out of the viewport and rebuilds it on the way back, and zen-asset:// responses never reach Chromium's HTTP cache, so every re-entry re-read the file from disk, sent it over IPC and decoded it again. Ten images produced 37 asset requests in a single down-and-up pass, and not one image element was ever reused. With realistic images that is a 12-25ms blank gap each time, which is the pop-in you are describing.

Live preview now keeps recently shown images decoded and reuses them:

asset requests        37 -> 16
image fetch+decodes   39 -> 15
fresh <img> nodes     56 -> 19  (24 reused)
read-scroll worst   29.2 -> 23.0 ms
flick worst         30.0 -> 22.5 ms

The cache is bounded by decoded pixels rather than image count, because a file's size tells you nothing about its decode cost. It is deliberately modest (about 64MB) so the app does not trade a lot of memory for a rare case. An image edited on disk still reloads, because the file's mtime is part of the cache key.

Did not reproduce: scrolling long notes is laggy. At 815 lines and 126k characters I measured a 16.7ms median frame, which is a clean 60fps, with zero long tasks, and that held on a fast continuous flick as well as a slow read-through. Same result with images and without.

Did not reproduce: React re-renders on every keystroke. Keystroke-to-paint in that same 126k character note sat at my measurement floor, so there was no measurable per-keystroke cost.

So the scrolling complaint is still open, and I would rather find the real cause than optimise something that is already fast. Something about your content is doing it that my synthetic note does not model, and the candidates behave very differently: large tables, KaTeX-heavy notes, Mermaid diagrams, very long unwrapped lines, or simply many more images than ten.

You offered to help test, so I will take you up on it. Any of these would help, in rough order of usefulness:

1. The note itself, or a redacted version that still lags. Structure matters far more than the words.
2. Failing that: roughly how many images, tables, code blocks, math expressions and Mermaid diagrams it contains, and whether the lag persists with live preview turned off (Settings, Editor).
3. Your OS, and whether the window is on a high-DPI or external display.

I am leaving this open until we have run that down.