Search usability (auto-complete): Ensure good live search performance by using a minimum amount of characters and a more relaxed search activation timeout delay to avoiding hammering your servers

This is an idea of a potential performance optimization.

Even with a fairly fast manticore-based search, Tiki should avoid creating excess work/stress (roundtrips/latency/IO/etc.) on the servers when doing live searches (i.e. filtering search as the user types). This will be useful for:

• The global searchbar
• Any field autocompletion that needs to search through extensive data (ex: things that need to search through the whole database, not just "categories names" for example)
• Automatic related items and duplicates detection (future feature) when creating new items
• Probably makes it easier for anyone with slow/high-latency internet connections, and mobile usage scenarios.

The logic and philosophy can be seen here:

• https://github.com/getting-things-gnome/gtg/issues/281 (fixed, and proven to have made a huge difference)
• https://github.com/Drive4ik/simple-tab-groups/issues/794 (fixed, and proven to have made a huge difference)
• https://gitlab.gnome.org/GNOME/nautilus/-/issues/1731 (a good general argument and theoretical overview of why this is relevant)
• https://gitlab.gnome.org/GNOME/gtk/-/issues/4133#note_1486168 (empirical proof provided)
• https://gitlab.gnome.org/GNOME/gedit/-/issues/398

It seems Tiki 24 already does have some (?) search typing timeout search activation delay built into it (if the top-right searchbar's behavior is any indication), however it has two problems:

• It's probably too quick/agressive, it feels like 100 or 200 miliseconds or something. I would recommend something like 500ms "after the user has stopped typing". Or if you want to get extra fancy, you could have a logarithmic/degressive timeout value based on the number of characters; ex: wait 1.5 seconds if there is only 1 or 2 characters typed, 1 second if there is 3 or 4 characters, 750ms if there is 5, and 500ms if there is more than 5 characters in the search query (no need to go lower than 500 ms afterwards).
• It currently searches even if there are very few characters. If you type a single character and wait a fraction of a second, it will run a search, and that will be very slow. In a global search, it should never immediately search for something with only 1 or 2 characters, and for anything less than 4-5 characters it should wait a fairly long time before triggering the search, as a search is more expensive when the query is imprecise and the search domain is large.
• If it's 0 characters, it should probably issue a "cancel / clear / reset search" command or something (assuming searches can be cancelled).

https://dev.tiki.org/item7938-Elasticsearch-vs-MySQL-vs-MariaDB-Search-usability-Timeout-based-search-activation-algorithm

1. 2023 05 10 181800