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.) |
| private String searchQuery = null; | ||
| private static final int delay = 50; // If the search string does not change after $delay ms, then the search task starts. | ||
| private static final int shortStringDelay = 200; // A longer delay for short search strings. | ||
| private static final int minDelay = 50; // Minimum delay in ms after the search string stopped changing before the search task starts. |
There was a problem hiding this comment.
Thank you for the PR. Good idea.
I think we could make the implementation a bit cleaner and easier to maintain. Instead of adding the debounce logic directly to SearchableBaseNoteFragment.java, would it make sense to move this into a small Kotlin helper class and use coroutines for the implementation?
For example:
class SearchHelper(private val fragment: Fragment) {
companion object {
private const val MAX_DELAY = 750L
private const val LAST_SEARCH_DURATION = 0L
// ...
}
fun checkOccurrences(onComplete: () -> Unit) {
fragment.lifecycleOwner(Dispatchers.IO) {
// ...
withContext(Dispatchers.Main) {
onComplete()
}
}
}
// if possible we can add `countOccurrences` here as well.
}This would give us lifecycle-aware code and would also remove the need for managing an ExecutorService and calling shutdownNow() explicitly.
One other suggestion: I think we can remove the comments and keep the variable/method names self-explanatory.
As we add more fixes and features to the fragment, mixing this logic directly into it could make the file increasingly difficult to follow.
I think the approach is good. Thanks again for the work on this.
2 participants
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.