Large markdown files (~10K lines) freeze the UI for a couple seconds on open

[cameronsjo]

Opened a ~900KB markdown file — 11,176 lines, 5,567 inline links, 1,868 ATX headings, basically a long list of bookmarks grouped by domain — and the window is unresponsive for a second or two before scroll wakes up. Theme switches and search keystrokes re-trigger it.

I poked around the source. The hot spot looks like the VStack in MarkdownView.swift around line 127:

ScrollView {
    VStack(alignment: .leading, spacing: 8) {
        ForEach(cachedBlocks) { block in
            blockView(for: block)
        }
    }
}

VStack lays out every child eagerly, so SwiftUI instantiates, measures (Core Text), and positions all 1,800+ blocks before painting the first frame. That's the freeze.

I tried swapping VStack for LazyVStack on a local branch and the open is sub-frame. There's a comment in MarkdownBlock.swift:10–13 showing you already debugged the LazyVStack id-getter hot path and made id a stored property, so the swap is safe now.

One catch worth knowing: textSelection(.enabled) inside a LazyVStack loses auto-scroll-during-drag, because off-screen rows aren't materialized when AppKit goes looking for the next selectable view. So the simple swap fixes the perf but trades away a native macOS interaction. There's probably a deeper fix worth its own issue (NSTextView-backed content view); I'm filing that separately.

Happy to send a PR with the LazyVStack change plus a two-pass scrollTo helper (needed because proxy.scrollTo(id, anchor:) to an unmaterialized item under-shoots on macOS 13) and a 150ms debounce on the search recompute path. Patch is small: +30/−9 lines, one file. Or you might want to take a different angle — say the word.

Repro file is just a long bullet list of [text](url) — date lines. Easy to synthesize, or I can attach the one I hit it with.

[b451c]

Partial fix shipped in v1.5.0; leaving this open for the rest.

What landed:

• Code blocks now render through NSTextView (via NSViewRepresentable) instead of SwiftUI Text(AttributedString). This eliminates the original v1.3.3 box-drawing-Unicode trap at the source.
• Parser chunks long bullet/link sections at blank-line boundaries every ≤30 lines, so an 11K-line bookmark file no longer becomes 95 enormous text blocks.
• Per-text-block plain-string and hasInlineMath cache built at parse time on the background thread — eliminates per-render String(attr.characters) + regex during scroll/resize/focus events.
• Search input is debounced 150ms, as you suggested.
• Loading indicator while parser runs.

What did NOT work, and why:

I tried LazyVStack first (your suggestion). It surfaced a second SwiftUI bug independent of the box-drawing one: rapid create/destroy of Text(...).textSelection(.enabled) instantiates SelectionOverlay (an internal NSTextField-backed shim) per visible block on every scroll frame. setFont → invalidateEffectiveFont → setNeedsDisplayInRect cascades saturate the main thread. Sample showed 99% CPU on SelectionOverlay.updateNSView even on small docs (~50 blocks). Reverted to eager VStack.

The proper fix is to also host text blocks in NSTextView (same pattern Sprint 4.1 used for code blocks). Then .textSelection(.enabled) is no longer needed and LazyVStack can come back. That's a larger refactor — touches table/blockquote/heading views, search highlight, and PDF export. Tracking it as the v1.6.0 milestone (overlaps with #11).

Net effect on your repro: opens are slower than ideal but no longer freeze, and scroll/theme-switch are smooth. Memory stays well under prior peaks.

Thank you for the rigorous bug report and the patch suggestion — keeping this issue open as the v1.6.0 anchor.