Search speed Improvements
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 1.4k
- Forks
- 354
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 43
Description
How to use GitHub
- Please use the 👍 reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Is your feature request related to a problem? Please describe.
My Nextcloud Instance is running on a Raspberry pi and searching (Ctrl+F) for Cards takes very long (Note: I have 248 Cards). My guess is that this is because all Cards are loaded again from the server (I don't know what else could be the reason for it). Sometimes this even leads to the Browser telling that a page is slowing it down and me having to type the search character for character for it to even work (Timeout?)
Describe the solution you'd like
I think it would be best for the search to be completely on the client side, since all Cards have to get loaded at least once anyways. To make #286 easier it would probably best to save all Cards in JavaScript to search them.
Describe alternatives you've considered
- Alternatively searching through the DOM could be easier to implement than storing it in JavaScript (e.g. set "display: None" if condition is not met. This could however reduce the performance for more advanced searches (or increase the Effort to add them) like in #286 but would probably still be faster than requesting all Cards from the server again.
- Improving the client code that processes the Server response (as mentioned in "Additional context") could improve the Performance but wouldn't work if the Server is the bottleneck (unless the next packet stops the previous one from processing which would probably more effort than having a Client-Side only search).
Additional context
- A search through 248 Cards with a simple Keyword with 5 characters took about 5 Seconds.
- When searching for long Keywords the response time seems linear to the amount of Characters (10 Characters took over 10sec). This is probably because for each change in the input field a request is sent to the server, the server has to process it and perhaps the client processes all responses one after the other instead of knowing that only the last one has to get processed.
Edit: Having the "Toggle compact mode" functionality on the Client-Side could be nice, too (having to wait for a second)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the Deck client-side search triggered by Ctrl+F and compare its request and response handling for the reported 248-card case. Check whether each input change sends a server request or processes older responses. Done means search responds promptly without unnecessary repeated server work, with behavior verified against the reported multi-character searches.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend, performance
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100