mirror of
https://github.com/emilk/egui.git
synced 2026-06-26 22:53:14 -04:00
4016dee2bd
## Summary `next_word_boundary_char_index` calls `char_index_from_byte_index` on every word-boundary segment. Since `char_index_from_byte_index` scans from the start of the string each time, this makes the function O(n·m) where m is the number of segments — effectively O(n²) for large texts. The fix replaces those repeated scans with a running char counter maintained as we iterate segments. Same results, O(n) instead of O(n²). ## The problem Any pointer interaction (click, double-click, drag) inside a `TextEdit` with a large text buffer triggers `pointer_interaction` → `select_word_at` → `ccursor_previous_word` → `next_word_boundary_char_index`. On a 500 KB buffer this takes ~30 seconds, freezing the application. ## Benchmark results Measured with cursor near end of text (worst case): | Text size | Before | After | Speedup | |-----------|--------|-------|---------| | 1 KB | 147 µs | 38 µs | 3.9x | | 100 KB | 1.2 s | 3.8 ms | 313x | | 500 KB | 30 s | 18 ms | 1,636x | Benchmark source: [`bench/word-boundary-perf`](https://github.com/hallyhaa/egui/tree/bench/word-boundary-perf) (separate branch, not part of this PR) ## Changes - `next_word_boundary_char_index`: replace `char_index_from_byte_index` calls with a `running_ci` counter (the fix — 6 changed lines) - New tests for `ccursor_previous_word`, `ccursor_next_word`, `select_word_at`, and a large-text performance test --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>