GNOME Bugzilla – Bug 644148
Searches too early in the overview, causing hang
Last modified: 2013-09-07 01:02:25 UTC
When I want to start an application what I'm usually doing is: <Super> + type name ... wait to see results <Enter>. The search is incremental so it starts searching as soon as I start typing. That means when I search for 'epi' to start Epiphany, say, it starts searching as soon as I hit 'e'. This causes an extremely undesirable effect in my opinion: the search box has 'e' in it, despite my having typed 'epi', a lengthy search is performed that returns almost all applications. Soon after those results are shown the search box has 'epi' in it, and Epiphany appears as the only result. We had more or less the same issue with Epiphany's in-page search for a while, and we had very good results with simply adding a timeout to delay searching while the user types at full speed (the timeout is hardcoded at 300ms). It is not perfect, but it does give a more pleasant experience and less wait time, so I would recommend adopting this same idea for the overview search box =) PS: I also have the exact same problem with GNOME2's "run" dialog
Actually, looking at the code it seems gnome-shell already has a timeout, it looks like my problem is just that the timeout is too small for my usual typing speed. 300ms fits me better =)
I also experience this problem, especially when there is only one letter in the entry. The behavior I'd like to have is something like this: the search entry should be immediatly responsive to user typing, without waiting for search results to appear, and in the meanwhile a spinner should appear somewhere to indicate that searching is in progress. The current behavior is too punishing, for example against typing errors.
In bug #645334 I suggested discarding searches of less than 3 characters, but it was marked as a duplicate of bug #645313 which seems to indicate that the performance issue was fixed... is this still a problem? (to me it still feels a bit slow even though it searches in <0.5 secs)
IMO timeouts are just a hack around the search being too slow.
So what do we do about this issue?
While I agree with Colin that this is just a hack for the search being too slow and blocking, I believe a higher timeout value would improve perceived performance and make the overview more usable in general, for now. Ideally we would have the search being done in a cancellable async so the UI would never block. I also believe that the situation has improved quite a bit already since I fist reported, but some I/O happening in the background is still able to make the search hang.
*** Bug 678571 has been marked as a duplicate of this bug. ***
Gustavo, is this now obsolete with the changes in 3.6?
Gustavo: Is this still an issue in 3.8 or 3.6?
I haven't seen a hang in a while. Maybe the fact that I have mostly been using SSDs for a while has something to do with it, but as far as I am concerned, this is fixed.
Closing as of comment #10.