search

Raku / doc-website

Tooling to build/run the documentation website
Artistic License 2.0
7 stars 10 forks source link

Limit search results to 500 #323

Closed donaldh closed 9 months ago

donaldh commented 9 months ago

When trying to use the search box, there was a significant delay between each char typed for the first couple of chars. Analyzing the time spent in Safari showed that when I typed 's' which had 3256 matches, 98% of the time was spent in style processing, i.e. rendering all of the results in the search results box. The only way to improve this is to reduce the number of entries we ever try to add.

Setting maxResults to 500 makes the search responsive and still delivers more results than is useful.

finanalyst commented 9 months ago

@coke this is not a trivial change. Needs discussion

On Mon, 4 Dec 2023, 17:11 Will Coleda, @.***> wrote:

@.**** approved this pull request.

— Reply to this email directly, view it on GitHub https://github.com/Raku/doc-website/pull/323#pullrequestreview-1762971839, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACYZHGIV4PFHDEBCHRESSLYHX72NAVCNFSM6AAAAABAGKGUR2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONRSHE3TCOBTHE . You are receiving this because you were assigned.Message ID: @.***>

finanalyst commented 9 months ago

Originally, I limited search results to 20, but there were complaints about not seeing the rest. 500 is an order greater, so perhaps is a better idea. 50 would be quicker. Another approach is to start filtering after a small number of characters, eg 2. This will also reduce filtered candidates. Before making the change I just want to document the reason 'unlimited' was chosen

On Mon, 4 Dec 2023, 17:09 Donald Hunter, @.***> wrote:

When trying to use the search box, there was a significant delay between each char typed for the first couple of chars. Analyzing the time spent in Safari showed that when I typed 's' which had 3256 matches, 98% of the time was spent in style processing, i.e. rendering all of the results in the search results box. The only way to improve this is to reduce the number of entries we ever try to add.

Setting maxResults to 500 makes the search responsive and still delivers more results than is useful.

You can view, comment on, or merge this pull request online at:

https://github.com/Raku/doc-website/pull/323 Commit Summary

File Changes

(1 file https://github.com/Raku/doc-website/pull/323/files)

Patch Links:

— Reply to this email directly, view it on GitHub https://github.com/Raku/doc-website/pull/323, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACYZHFJGGV2D56QS5TWQO3YHX7VVAVCNFSM6AAAAABAGKGUR2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDIMZTGQ3TMNA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

donaldh commented 9 months ago

Agree there's no right answer for where to truncate results and maybe 50 to 100 is a reasonable limit that is responsive. I picked 500 because it was responsive enough while also high enough it's not going to cut out anything but heading and index matches. Maybe just need to inform the user when the results are truncated.

I thought about setting threshold: 2 but it's legitimate to want to search for single character things like operators. e.g. + which has 41 matches.

coke commented 9 months ago

More complex would be to combine the chars and only send a request after an idle time after typing (picking that threshold is probably even more finicky)

2colours commented 9 months ago

More complex would be to combine the chars and only send a request after an idle time after typing (picking that threshold is probably even more finicky)

Yes, I also thought about this - the only problem is that it's also not trivial to make that look clever, rather than "why is it doing nothing for (e.g) 2 seconds"... perhaps it would require a little animation or something... but then we aren't much like frontend guys.

donaldh commented 9 months ago

More complex would be to combine the chars and only send a request after an idle time after typing (picking that threshold is probably even more finicky)

Yes, I also thought about this - the only problem is that it's also not trivial to make that look clever, rather than "why is it doing nothing for (e.g) 2 seconds"... perhaps it would require a little animation or something... but then we aren't much like frontend guys.

I don't think an idle timer would help since the browser freeze will still happen while it renders the v large result set. It might interrupt the typing less often but the stall would still happen and interrupt whatever you try to do.

2colours commented 9 months ago

don't think an idle timer would help since the browser freeze will still happen while it renders the v large result set. It might interrupt the typing less often but the stall would still happen and interrupt whatever you try to do.

I think it is okay if the browser freezes while searching, IF the search is about something you actually want. If you want to search for the letter a, let it freeze really. The idle is to avoid always searching for partial input that has much more results than what one actually wanted to search for.

patrickbkr commented 9 months ago

Is there a reason why limiting the number of search results is a bad idea (irrespective of other ideas that could also be nice)? If not, can we then just use for the simple solution for now?

finanalyst commented 9 months ago

Lets go with the simpler solution for the time being.