GNOME Bugzilla – Bug 614971
Initialize search engines on demand
Last modified: 2015-03-07 21:44:56 UTC
Initializing search engines can take some time (we have three at the moment) and every time the file chooser window is opened it slows down things even when Search is not used. E.g. initializing tracker can take very long time (wrt to usability) as long the client can now spawn the daemon (and wait for his initialization). We call search_is_possible() on initialization when deciding whether to show a Search option in the sidebar. The simple search engine, used as a fallback, is basically available all the time (well, when threads are supported) so we can avoid this call very well nowadays.
Created attachment 158055 [details] [review] proposed patch We can easily avoid search_is_possible() with the previous assumption in mind. Initialization of search engines is handled by search_start_query() then. This however won't avoid the delay initializing the search engines, just moves it to a different place.
Review of attachment 158055 [details] [review]: Good. Please go ahead and push this.
(In reply to comment #2) > Review of attachment 158055 [details] [review]: > > Good. Please go ahead and push this. Thanks, committed as faf0beede02932923290ac3d69eb5102f2ca72c2
Created attachment 158122 [details] [review] [PATCH] Set tracker daemon connection timeout to 1 sec. My last patch in this matter is setting a reasonable timeout for connecting to the tracker service. Starting tracker is fast on my machine but could take seconds on old machines. The result is that the tracker daemon is always autostarted (see below) but availability is racy. The timeout is set to one second, this is a question for discussion. It's only noticeable when search is performed, theoretically we don't need to set any timeout (leaving it at G_MAXINT) with the previous patch. I've also filed bug 615050 on tracker requesting an API to check whether the daemon is running. Once it's implemented, I'll add support for that.
(In reply to comment #4) > Created an attachment (id=158122) [details] [review] > [PATCH] Set tracker daemon connection timeout to 1 sec. > > My last patch in this matter is setting a reasonable timeout for connecting to > the tracker service. Starting tracker is fast on my machine but could take > seconds on old machines. The result is that the tracker daemon is always > autostarted (see below) but availability is racy. > > The timeout is set to one second, this is a question for discussion. It's only > noticeable when search is performed, theoretically we don't need to set any > timeout (leaving it at G_MAXINT) with the previous patch. The timeout is not for connecting, it is for D-Bus requests... the timeout is used with dbus_g_proxy_set_default_timeout(). If this is too low (like 1 second) and the daemon has to be started, then it is likely to not start quick enough. The daemon is usually running on start up of course so this is not a likely situation in most cases.