After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 655850 - Initial search in activities overview is slow due to I/O
Initial search in activities overview is slow due to I/O
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-08-02 21:17 UTC by Jean-François Fortin Tam
Modified: 2012-11-07 14:45 UTC
See Also:
GNOME target: ---
GNOME version: 3.5/3.6



Description Jean-François Fortin Tam 2011-08-02 21:17:29 UTC
This is my biggest gripe with gnome-shell right now: on anything but the fastest machine with a solid state drive, on the first attempt you make at searching/launching an application or file, it will lag significantly for a few seconds.

My guess is that it only parses all the application .desktop files at that moment when you run a search for the first time, with disastrous consequences in terms of reactivity. This may seem trivial, but many users get annoyed at this problem especially in cases where you logout/switch users often.

I'm wondering if there would be some way of lazy-loading this stuff in a background process on startup (when the gnome session i/o is done), instead of waiting on the user to bump into this problem?
Comment 1 Jean-François Fortin Tam 2011-08-02 21:21:20 UTC
Another possible (maybe complementary) approach would be to discard searches of less than 3 characters (one could say the search results would be too many/imprecise anyway) thus preventing "hammering" the search system and also buying some time for it to do its I/O work.
Comment 2 Jasper St. Pierre (not reading bugmail) 2011-08-02 23:14:26 UTC
Can you make sure it's due to IO? Does the disk light blink a ton?

Otherwise, this is a dup of #647778.
Comment 3 Jean-François Fortin Tam 2011-08-03 03:37:40 UTC
I'm not sure. I just did some more testing, and the IO happens only on the first login (or 'echo 3 > /proc/sys/vm/drop_caches' and restart the shell).

So,
- there is IO
- if you logout and relogin without dropping caches, the initial search slowdown will happen... so it looks like you might be right about this being a potential duplicate of bug #647778. I just find it a bit surprising that IO would not have anything to do with it.
Comment 4 Jean-François Fortin Tam 2011-08-03 03:38:59 UTC
Hm, I think my previous comment is unclear.
- on a warm start, the initial search is slow but there is no IO
- on a cold start, the initial search is slow and there is IO
Comment 5 John Stowers 2011-08-03 20:55:48 UTC
I mentioned this in bug 655811 too, but how big is your ~/.local/share/recently-used.xbel?

I notice search gets slow(er) when this file is large (and useless when files listed in there no longer exist, but that is bug 653064)
Comment 6 Jean-François Fortin Tam 2012-01-23 16:12:07 UTC
Hey John, somehow I missed your question. My recently-used.xbel file is not unusually large (to gnome standards): 360K.

Still seeing this stuff on 3.2. Any netbook or older computer (with IDE hard drives/a slower GPU) will easily reproduce this.
Comment 7 Jean-François Fortin Tam 2012-10-21 20:40:00 UTC
From my tests, in 3.6 there is no more noticeable lag anymore when searching, even on a cold start. The only remaining lag is the very first time you open the Activities overview on a cold start, about 1-2 seconds, but I guess I can live with that.
Comment 8 Matteo Settenvini 2012-10-27 13:11:47 UTC
Well, there's no more lag for searching, that's true. But the first time I open the Activities overview on my laptop, now the whole UI is unresponsive for about 7-10 seconds. :-| The system looks completely hanged.
Comment 9 Jean-François Fortin Tam 2012-11-07 14:45:18 UTC
Follow-up in bug #687849.