Performance issue with search-as-you-type
Closed this issue · 5 comments
While I love the concept, this has a serious performance issue when dealing with very large journal entries - exactly when you need it most!
The problem is that it initiates the search immediately after the very first letter you type, without any delay to wait for further keystrokes. In a large journal entry, a single common letter will have a huge number of matches for it to handle. The result is that Foundry freezes for a while. Eventually it does unfreeze, at which point it will register your remaining keystrokes and execute the search you actually wanted. But the freeze is significant.
It should either wait to execute the search until a certain period of time (even a quarter second) elapses without a keystroke, or until at least three or four characters have been entered.
Edit: Note I am specifically talking about searching within a single journal entry. I haven't tried the search across journals.
Hi @KenGitsIt - I think this a great idea. I'll add a configurable debounce/delay for performance shortly and tag you when complete. There are also some performance optimisations that could be made under the hood.
@KenGitsIt - V0.0.10 should have some improved performance and some options that may be of interest to you. If you confirm some improvement then I'll close this ticket for now.
The performance is significantly improved! Thank you for addressing the issue so quickly.
With the (new?) preview count limits, however, I think a functionality issue has been introduced. As far as I can tell, there is no way to access the additional search results beyond the preview count limit. Or am I missing something in the UI? Based on the way that search typically works in other contexts, I would have expected one of two things: either the option to click on the message about additional results, and that would have expanded the full list, or a pair of forward/backward buttons to navigate through the results even without the preview.
The above, although probably introduced with this fix, perhaps deserves to be tracked in a separate issue, since the performance issue is resolved.
Hi @KenGitsIt. Actually, the more results section has always been static and it never occured to me to make it dynamic the way you describe. I'll add that as a separate issue and mark as enhancement.