perf(search): adaptive debounce and background matching for in-note search#3249
perf(search): adaptive debounce and background matching for in-note search#3249MiMoHo wants to merge 1 commit into
Conversation
…earch The in-note search started almost immediately (50/200 ms static delay) after each typed character and ran counting, occurrence lookup and span highlighting synchronously on the main thread. In long notes this freezes the UI after the very first typed letter. - The debounce delay now adapts to the measured duration of the previous search + highlight pass: clamp(2 x lastDuration, 50 ms, 750 ms), plus 150 ms for queries of up to 3 characters. Short notes keep the current snappy behavior. - Occurrence counting runs on a background executor. A generation counter cancels superseded searches, so only the newest query result is applied (as suggested in nextcloud#1729). - jumpToOccurrence no longer allocates full lower-case and substring copies of the note content per query; the recursive, case-sensitive indexOfNth got replaced by a single case-insensitive matcher pass. Fixes nextcloud#1729 Helps nextcloud#2489 Signed-off-by: MiMoHo <37556964+MiMoHo@users.noreply.github.com>
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
1 participant
Problem
Fixes #1729. In long notes, in-note search starts searching after the very first
typed letter. Counting, nth-occurrence lookup and highlighting all ran synchronously
on the main thread, so a single-letter query with thousands of matches freezes the
UI for seconds (see the "&"-prefix workaround described in #1729).
Changes
with the measured duration of the previous search + highlight pass —
clamp(2 × lastDuration, 50 ms, 750 ms), plus 150 ms for queries ≤ 3 characters.Short notes keep the current snappy behavior (addressing the earlier concern in
Slow search in long notes #1729 that a fixed 1 s delay would hurt every use case), while long notes
automatically get a delay long enough to let the user finish typing. Measuring
real duration is more robust than scaling by content length, because the cost is
dominated by the number of matches.
background executor; a generation counter discards superseded results ("some kind
of Cancel event", as suggested by the maintainer in Slow search in long notes #1729). Only the newest query
is highlighted, on the main thread.
jumpToOccurrence()allocated a fulltoLowerCase()copy plus asubstring(0, index)copy of the entire note perquery. Replaced by a single case-insensitive
Matcherpass; the recursive,case-sensitive
indexOfNthis gone (it also disagreed with the case-insensitivecounting/highlighting).
Not covered
The remaining per-keystroke cost of the editor itself lives in
nextcloud-commons:markdown— see the companion PRstefan-niedermann/nextcloud-commons#436 (executor reuse in
EditorStateNotifier, debouncedSearchHighlightTextWatcher). BumpingcommonsVersionafter its release will address #2489 / #3162.Testing
./gradlew test).continue typing — the UI no longer freezes after the first letter; searching in a
short note behaves as before.