3eddbb7f4e72f7a6e3b60f4b0a586db2f6c2ae6c
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Kirill Bulatov
|
7265ff479a |
language: Cache buffer syntax highlighting per row chunk (#63145)
Closes https://github.com/zed-industries/zed/issues/63730 Related to #52340 and #43460 Based on https://github.com/zed-industries/zed/pull/63138 and needs it to be merged first. `BufferSnapshot::chunks` re-ran the tree-sitter highlight query over the requested range on every call, so scrolling and cursor movement paid the full query cost per frame. Highlight runs are now computed once per 50-row chunk (the same `RowChunks` that back bracket colorization), resolved against the current `HighlightMap` at compute time, merged into `(Range<usize>, HighlightId)` runs, and kept in a cost-budgeted per-buffer LRU (10MB). Entries reuse the `ResolvedHighlights` representation from #63138: each stores the grammars and maps it was resolved against and is served only while every map is pointer-identical (`is_current`), so theme changes and grammar reloads invalidate structurally, with no invalidation hooks and no global state. Edits and reparses drop the cache through the existing `TreeSitterData` swap. Chunks spanning more than 64KB bypass the cache and fall back to direct querying, so files with giant lines behave as before. ## Benchmarks `editor_render_highlighted` and `editor_render_highlighted_minimap` benches (`cargo bench -p benchmarks --bench editor_render`) move the cursor through a generated 10K-line Rust file with real tree-sitter highlighting, with and without the minimap. The benches are new in this PR, so the baseline is the same binary with `ZED_DISABLE_HIGHLIGHT_CACHE=1`, which routes rendering through the pre-existing direct-query path. Run 1 — baseline, cache disabled: ``` editor_render_highlighted time: [1.7164 ms 1.7377 ms 1.7604 ms] editor_render_highlighted_minimap time: [12.273 ms 12.407 ms 12.549 ms] ``` Run 2 — cache enabled: ``` editor_render_highlighted time: [1.4572 ms 1.4597 ms 1.4627 ms] change: [-16.378% -14.944% -13.526%] (p = 0.00 < 0.05) editor_render_highlighted_minimap time: [9.2750 ms 9.3213 ms 9.3744 ms] change: [-25.800% -24.872% -23.930%] (p = 0.00 < 0.05) ``` Over the same runs, GPUI reports window draw mean 0.81 ms → 0.68 ms and p99 1.06 ms → 0.76 ms without the minimap, and mean 5.14 ms → 4.12 ms, p99 6.12 ms → 4.75 ms with it. The relative deltas held across two independent sessions (-14.1…-14.9% and -20.7…-24.9%), while absolute times drift a few percent with machine state. Release Notes: - Improved editor rendering performance in syntax-highlighted files, especially with the minimap enabled |
||
|
Kirill Bulatov
|
ed192bf4f1 |
markdown: Cache code block syntax highlighting at parse time instead of re-highlighting every frame (#63138)
Part of https://github.com/zed-industries/zed/issues/57349 `MarkdownElement` re-highlights every code block with tree-sitter on every frame. Each visible code block pays a full parse per frame, which makes agent panel streaming and hover popovers janky once the content grows. This PR computes code block highlights once, in the background parse task, instead of at render time: - Highlights are resolved into `(Range<usize>, HighlightId)` runs at parse time; each entry stores the grammar and `HighlightMap` it was resolved against and is served only while the grammar still holds the pointer-identical map (`ResolvedHighlights::is_current`), so theme changes need no invalidation hooks, and a block whose entry went stale falls back to direct fragment highlighting at render until the next parse. - `Language::highlight_text_resolved` memoizes results in a content-keyed LRU (4MB budget, 512KB per-entry cap), so the re-parses triggered by streaming appends reuse the highlights of unchanged blocks instead of re-running tree-sitter on them. - Blocks larger than the per-entry cap bypass the cache and are highlighted directly, as before. `CostBudgetedLru` is generic rather than specialized because a follow-up PR reuses it for per-buffer highlight caching in `BufferSnapshot::chunks`; the capture flattening keyed by grammar index (`HighlightCaptureRef`) is shared with that follow-up as well. ## Benchmarks `cargo bench -p benchmarks --bench markdown_renderer` renders generated documents that mix paragraphs, headings, tables, and Rust code blocks. **Run 1 — baseline, `main` (`ee2366a395`):** ``` Markdown render/min_bytes/5000 time: [1.2956 ms 1.2974 ms 1.3016 ms] Markdown render/min_bytes/10000 time: [1.7919 ms 1.7955 ms 1.8026 ms] Markdown render/min_bytes/50000 time: [6.5510 ms 6.6241 ms 6.6671 ms] Markdown render/min_bytes/250000 time: [37.644 µs 2.4819 ms 4.3791 ms] <- bimodal already on main ``` **Run 2 — this branch:** ``` Markdown render/min_bytes/5000 time: [940.11 µs 945.28 µs 948.79 µs] change: [-29.317% -28.385% -27.607%] (p = 0.00 < 0.05) Markdown render/min_bytes/10000 time: [1.1162 ms 1.1331 ms 1.1407 ms] change: [-40.859% -39.151% -37.719%] (p = 0.00 < 0.05) Markdown render/min_bytes/50000 time: [2.4943 ms 2.9225 ms 3.1051 ms] change: [-80.088% -67.885% -58.058%] (p = 0.00 < 0.05) Markdown render/min_bytes/250000 time: [43.442 µs 44.661 µs 45.514 µs] change: [-98.210% -95.806% +5.5167%] (p = 0.17 > 0.05) ``` Over the same runs, GPUI reports window draw mean 2.22 ms → 1.26 ms, p99 31.2 ms → 16.0 ms, and the share of frames that blow the frame budget drops from 3.9% to 2.0%. Note: at the 250,000-byte case root blocks render lazily, which makes the measurement bimodal and inconclusive in both configurations. Release Notes: - Improved rendering performance of markdown code blocks (agent panel, hover popovers, markdown preview) |