Closed jw3 closed 1 year ago
It looks like the GTK refilter()
on line 155 in searchable_list.py
is likely the culprit of the search slowness.
Reference: https://docs.gtk.org/gtk3/method.TreeModelFilter.refilter.html
As far as the time delay goes, it appears that we are already using the GTK built-in delay for searches as described here: https://docs.gtk.org/gtk3/class.SearchEntry.html
To make filtering appear more reactive, it is a good idea to not react to every change in the entry text immediately, but only after a short delay. To support this, GtkSearchEntry emits the GtkSearchEntry::search-changed signal which can be used instead of the GtkEditable::changed signal.
https://docs.gtk.org/gtk3/signal.SearchEntry.search-changed.html
The GtkSearchEntry::search-changed signal is emitted with a short delay of 150 milliseconds after the last change to the entry text.
In glade/searchable_list.glade
on line 39 we are using <signal name="search-changed" handler="on_search_changed" swapped="no"/>
For a System Trust DB with 35894 entries:
1 character (35894 -> 34244) ~38 seconds 2 characters (34244-> 12263) ~38 seconds 3 characters (12263 -> 559) ~4 seconds 4 characters (559 -> 545) ~0.3 seconds
3 Characters (35894 -> 541 files) ~30 seconds 5 characters backspaced to 1 character (541 -> 34244 ) ~78 seconds 1 character to 3 characters after backspacing (34244 -> 958) ~68 seconds 3 characters to 5 characters (958 -> 545) ~0.3 seconds
@jw3 @dorschs57 How would you feel about checking the number of entries in the system trust db when we start the app and if there are more than some threshold (5k?) we display a button where the list is. The button would have text along the lines of "There are a large number of entries in the db. Please begin a search or press this to display all entries". I think this would let us start a search without going through every row to check visibility until there are fewer entries or let the user know performance might suffer.
display a button where the list is.
Sounds like something that would go with #520 rather than this one.
short delay of 150 milliseconds
This sounds familiar. IIRC in gtk3 this cant be changed, in gtk4 it can.
If that was a 1 second delay it might make all the difference.
Two thoughts.
I am wondering if (1) isn't just the best way until we see what changes as a result of #520.
?
The search bar to filter the system trust list is very slow once there are any significant number of entries.
20K entries is a good number for example.