perf(text-buffer-view): stream word wrap for large chunks #471
Conversation
Word wrapping large single-line files (minified JavaScript, continuous logs) was slow. The old getWrapOffsets() precomputed all word boundary positions for the entire chunk before wrapping began. Multi-megabyte files produced arrays with tens of thousands of entries, most unused since wrapping only needs boundaries within the current wrap width. Added a hybrid strategy based on chunk size. Chunks larger than 64KB now use findWordWrapPosition(), which scans only up to wrap_width columns per line and returns the last word boundary within that window. This stops early instead of walking the full chunk. Smaller chunks keep the cached approach where the upfront cost pays off through cache locality. Note: wrap-break detection now honors `width_method` in the cached path. This changes semantics for `.wcwidth` and `.no_zwj` (per‑codepoint breaks; ZWJ forces a break), while `.unicode` behavior is unchanged. This aligns cached offsets with the streaming path and cursor movement. The streaming path uses per-codepoint widths without full grapheme state, so complex emoji or Indic sequences may wrap differently than cached, but only in chunks over 64KB containing such sequences at wrap boundaries.
|
Cool! I like the approach, I've been meaning to do something like that for graphemes as well. |
|
@simonklee I added some improvements in #473 after investigating this. It fixes the resize wrapping performance for the minfied JS in the demo for me. Does it help for you here as well? I'll work on memory usage for this as well as not all wrap points are used, I'd go with incremental calculation and caching, to not introduce two different paths in the already complex wrapping logic, so it only calculates one wrap break per line and caches it, accumulating in the cache when resizing a lot (not common), so it can re-use cached wrap breaks and only tries to find a new one if no suiting one is found for the range. |
Thanks, when I thought more about this I kind of regretting adding another code-path so I agree with your observation. I will have a look at your branch and see how it performs for me. |
|
Tested your implementation and it works well for me locally, not only that, the fix is 10x simpler. |
2 participants
Note: I wasn't sure weather to add this as an issue or a PR, so I went with PR,
but feel free to close if you want to discuss approach first.
The gist of this change is to improve word wrapping performance on large
single-line chunks by switching to a streaming approach instead of
precomputing all word boundaries.
before
main.mp4
after
word-wrap.mp4
Word wrapping large single-line files (minified JavaScript, continuous
logs) was slow. The old getWrapOffsets() precomputed all word boundary
positions for the entire chunk before wrapping began. Multi-megabyte
files produced arrays with tens of thousands of entries, most unused
since wrapping only needs boundaries within the current wrap width.
Added a hybrid strategy based on chunk size. Chunks larger than
64KB now use findWordWrapPosition(), which scans only up to wrap_width
columns per line and returns the last word boundary within that
window. This stops early instead of walking the full chunk. Smaller
chunks keep the cached approach where the upfront cost pays off
through cache locality.
Note: wrap-break detection now honors
width_methodin the cachedpath. This changes semantics for
.wcwidthand.no_zwj(per‑codepoint breaks; ZWJ forces a break), while
.unicodebehavioris unchanged. This aligns cached offsets with the streaming path and
cursor movement.
The streaming path uses per-codepoint widths without full grapheme
state, so complex emoji or Indic sequences may wrap differently than
cached, but only in chunks over 64KB containing such sequences at wrap
boundaries.
Benchmarks:
Baseline
31a5cc2(main) -> Currentc688b4a(perf/word-wrap)