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 614971 - Initialize search engines on demand
Initialize search engines on demand
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: Tomas Bzatek
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2010-04-06 15:38 UTC by Tomas Bzatek
Modified: 2015-03-07 21:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (1.27 KB, patch)
2010-04-06 15:56 UTC, Tomas Bzatek
committed Details | Review
[PATCH] Set tracker daemon connection timeout to 1 sec. (1.27 KB, patch)
2010-04-07 14:20 UTC, Tomas Bzatek
none Details | Review

Description Tomas Bzatek 2010-04-06 15:38:38 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.
Comment 1 Tomas Bzatek 2010-04-06 15:56:55 UTC
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.
Comment 2 Federico Mena Quintero 2010-04-06 16:55:42 UTC
Review of attachment 158055 [details] [review]:

Good.  Please go ahead and push this.
Comment 3 Tomas Bzatek 2010-04-07 13:10:03 UTC
(In reply to comment #2)
> Review of attachment 158055 [details] [review]:
> 
> Good.  Please go ahead and push this.
Thanks, committed as 
faf0beede02932923290ac3d69eb5102f2ca72c2
Comment 4 Tomas Bzatek 2010-04-07 14:20:35 UTC
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.
Comment 5 Martyn Russell 2010-04-13 13:00:00 UTC
(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.