Slow search in long notes

[MiMoHo]

Please use GitHub reactions 👍 to show that you are affected by the same issue. Please don't comment if you have no relevant information to add!

Describe the bug
When searching for a term in a very long note, the app doesn't wait for the user to finish typing but starts searching instantly which results in finding matches for the first letter and then recognizing that the user typed a much longer term and starts searching again.

To Reproduce
Steps to reproduce the behavior:

1. Create a new note, add a novel of text to it and save by going back to the overview.
2. Reenter the note and type a word in the search bar.
3. First, the app will only show one letter in the search bar, but you can keep typing on the keyboard. Do so.
4. The first search iteration will highlight all findings for the first letter of the word and then starts over instantly again for the full word.

Expected behavior
There should be a search delay of one second after the user stopped typing before the search is triggered. This will result in cutting down the search time by half in long notes.

Screenshots
Search results after the first iteration while the second iteration is running and will produce findings for the entire word soon

Smartphone (please complete the following information):

• Nextcloud Notes-Version (android app): 4.0.0 RC1
• F-Droid or Play Store: FDroid
• Android-Version: 11
• Device: Sony Xperia

Server

• Nextcloud version: 26.0.0
• Nextcloud Notes version (server app): 4.7.2

Stacktrace

[stefan-niedermann]

There should be a search delay of one second after the user stopped typing before the search is triggered. This will result in cutting down the search time by half in long notes.

No, there shouldn't. There already is a delay of 50ms. Waiting for a whole second before starting a simple search in any note for each use case would be terrible.

long notes

Could you please define your long "note"? Are we talking about 100 characters? 1k? 10k? 100k? Maybe you should consider to split your book up into multiple smaller notes?

Or can you contribute a search algorithm which is faster at the same O notation? You can find the currently used algorithm here.

I guess, what actually would help was some kind of Cancel event to stop the current search iteration and start from scratch as soon as a new input parameter arrives.

In any way, this can be considered as "enhancement", but I can't see any bug here 😉

[cooperra]

I'm glad to hear there's already some debouncing implemented, but it doesn't seem to be working for me.

Workaround

My workaround is to type an infrequent character like "&" or another symbol before typing my actual query. Once I've finished, I delete the "&", and I quickly see what I actually wanted. If I forget the "&", I will actually kill the app and start over. It is that slow.

I think this works because it's the highlighting that's so slow. The fewer results, the faster it goes. The initial "&" query is very fast, but a common letter like "e" is unusably slow. If I ensure that there are never very many results at once as I type, it works fine, but you have to admit it's a ridiculous workaround.

A little background for my use case, which I realize is unusual:

I use Notes to log activities in my day, so I append to a single note frequently. I realize I can split it into multiple notes, and have done so before, but I believe there's room for improvement here. I mainly use the search feature to work around another issue where Notes sometimes forgets my place and jumps to the top of the note (on orientation change or connecting a bluetooth keyboard). This is inconvenient because I always want to append to the bottom of this note. My note is long enough that manually scrolling is time consuming. My workaround is to search for the string "eof" which I keep at the bottom of my note.

Here's exactly what happens if I try to search the normal way:

The file is 398kb, but the issue started much earlier.

• I type "eof" as quickly as possible and the app immediately freezes for several seconds. Only the "e" is visible in the search box.
• At 20 seconds, I get the first "app not responding" prompt and bypass it.
• At 1 minute and 29 seconds, all of the "e"s are highlighted on-screen.
• At 3:42, "eof" appears in the search box, but only "e"s are still highlighted.
• At 4:10, my phone fell asleep. After immediately waking it, the app is totally black (I use dark mode) but the keyboard is still visible. Eventually, I see the notes list, so the search never completes.
• I retried the process keeping the phone awake, and it took 8 or 9 minutes for the first "eof" result to highlight.

Another note, the vibrations on my keyboard after the first character are delayed too, like 3 seconds. It's possible the app is receiving the rest of the input after the 50ms window, which would explain why the debouncing isn't helping.

Suggestions and ideas:

• Fix the resetting the scroll position bug to eliminate the finding-to-where-you-left-off usecase (a more common problem).
• Abort searches when more text is typed in the search box.
• Don't hog the UI thread, so that more text can be typed in.
• Abort or defer searches/highlights that take a really long time.
• Only highlight the text that will be on screen first, then do the rest over time or something less intrusive.
• Consider a longer debouncing period for queries shorter than three characters.
• Consider a longer debouncing period in general.
• Consider a longer debouncing period for long files. If the file is long, there's not much value in seeing immediate feedback for every character. The view would jump around.
• Invesitate debouncing to see whether it works as intended.
• Consider a non-incremental search for big files. Let the user hit the submit button on the keyboard to trigger the search.
• Investigate debouncing to see whether it works as intended.

Well, I didn't expect to find the bug, but look at this: cb42949 It looks like the first character has no delay!