GNOME Bugzilla – Bug 785380
On systems with slower disks, overview search is unusable
Last modified: 2021-07-05 14:08:54 UTC
The overview search is close to unusable on systems with slower SSDs or eMMC (and possibly also any spinning disk), as gnome-shell makes D-Bus spawn loads of separate D-Bus services, most of which load nearly the whole of the application in the backend. Systems which implement similar functionality, or at least Spotlight in iOS and macOS, have the applications feed data into a single database created for the purpose, which is then searched, rather than applications individually providing data. Ideally, we'd get all this data from Tracker instead of spawning 15 different backends killing the "go to overview" performance on devices such as low powered tablets and convertibles. Disabling the Search functionality made my Surface 3's "go to overview" functionality usable.
We ran into this some time ago on Endless, but I thought it was because we were installing dozens and sometimes hundreds of apps with search providers; didn't realize it was a problem on stock gnome-shell. Our solution, since the problem was mainly with apps' offline content databases, was to instead export only one search provider for all the offline content apps together. You can see the result here: https://github.com/endlessm/eos-knowledge-services/blob/master/search-provider/eks-search-provider.c Our solution isn't really useful for solving this in GNOME, since it is specific to the offline content stuff. But let me know if I can help think about a better solution. (I don't know anything about Tracker though.)
The problem I think is understood. Starting tens of fairly heavy applications in the background when you type a letter in the overview will not work unless you have the fastest of machines and disk. This is an article about when iOS introduced Spotlight to third-party apps, in iOS 9: https://arstechnica.com/apple/2015/09/ios-9-thoroughly-reviewed/5/#h3 Here the apps are the ones feeding into a database, which the search screen will consume. There are currently only a few "types" of GNOME-shell search providers: - ones showing running information (Terminal, Boxes). Those types can stay, we'd just need to make sure that the search provider isn't instantiated when there aren't any running instances - those where data is static (Characters, Recipes, Settings). The data could be fed into the database at package install time. - those with dynamic data (Contacts, Notes, Documents) where indexing data needs to be fed from the app to the database. [1] - those with really dynamic data (Calculator), probably a special case amongst the special cases The smoothest way to get this fixed would be to: - Make it possible for search providers to mark themselves as "never launch", fix Terminal and Boxes - Make it possible for search providers to mark themselves as "disabled by default", make, say, Recipes, Weather, disabled by default - Add a tracker client to gnome-shell - Make it possible for a search provider to give a Tracker query instead of launching a D-Bus service, test this with Files for example [2] - Make it possible to feed data into Tracker, and also remove it, at application install/upgrade time, combined with the app providing the query, test this with Settings, or Characters At least the first two are low-hanging fruits. [1]: We'd probably need the concept of background applications to allow those types of apps to update from the network, in the background, when policy allows it. A wider problem. [2]: Will likely be a bit more complicated with sandboxing
Created attachment 358320 [details] [review] remoteSearch: Allow search providers not to auto-start This would be used by search providers which only operate on data in the running instance, such as the terminal's search provider which finds the shell in the tab matching the search text.
(In reply to Bastien Nocera from comment #2) <snip> > The smoothest way to get this fixed would be to: > - Make it possible for search providers to mark themselves as "never > launch", fix Terminal and Boxes AutoStart=false with the attached patch. Untested, mind you. > - Make it possible for search providers to mark themselves as "disabled by > default", make, say, Recipes, Weather, disabled by default This is already possible through "DefaultDisabled=true". > - Add a tracker client to gnome-shell > - Make it possible for a search provider to give a Tracker query instead of > launching a D-Bus service, test this with Files for example [2] > - Make it possible to feed data into Tracker, and also remove it, at > application install/upgrade time, combined with the app providing the query, > test this with Settings, or Characters
Review of attachment 358320 [details] [review]: ::: js/ui/remoteSearch.js @@ +118,3 @@ } + remoteProvider.AutoStart = true; Style nit: autoStart @@ +196,3 @@ proxyInfo = SearchProviderProxyInfo; + let g_flags = Gio.DBusProxyFlags.DO_NOT_LOAD_PROPERTIES; The bit where the variable is used is missing from the patch.
Created attachment 359793 [details] [review] remoteSearch: Allow search providers not to auto-start This would be used by search providers which only operate on data in the running instance, such as the terminal's search provider which finds the shell in the tab matching the search text.
(In reply to Florian Müllner from comment #5) > Review of attachment 358320 [details] [review] [review]: > > ::: js/ui/remoteSearch.js > @@ +118,3 @@ > } > > + remoteProvider.AutoStart = true; > > Style nit: autoStart Fixed. > @@ +196,3 @@ > proxyInfo = SearchProviderProxyInfo; > > + let g_flags = Gio.DBusProxyFlags.DO_NOT_LOAD_PROPERTIES; > > The bit where the variable is used is missing from the patch. That's my brain getting confused by the argument also being called that, fixed.
Review of attachment 359793 [details] [review]: One style nit left, otherwise looks good to me ::: js/ui/remoteSearch.js @@ +196,3 @@ proxyInfo = SearchProviderProxyInfo; + let g_flags = Gio.DBusProxyFlags.DO_NOT_LOAD_PROPERTIES; Our coding style uses camelCase for variable names, so 'g_flags' violates that. However there's a good reason to go with that name anyway ... @@ +207,3 @@ g_interface_info: proxyInfo, g_interface_name: proxyInfo.name, + g_flags: g_flags }); ... if you take advantage of modern javascript here and replace "g_flags: g_flags" with the synonymous shorthand "g_flags"
Created attachment 359794 [details] [review] remoteSearch: Allow search providers not to auto-start This would be used by search providers which only operate on data in the running instance, such as the terminal's search provider which finds the shell in the tab matching the search text.
Review of attachment 359794 [details] [review]: The last review was meant as "fix the comment one way or the other, then push" :-)
(In reply to Florian Müllner from comment #8) <snip> > ... if you take advantage of modern javascript here and replace "g_flags: > g_flags" with the synonymous shorthand "g_flags" I write Javascript like I write C code, so... (In reply to Florian Müllner from comment #10) > Review of attachment 359794 [details] [review] [review]: > > The last review was meant as "fix the comment one way or the other, then > push" :-) gnome-shell isn't branched though, so should I also do that, or did you want it in 3.26?
I don't see any harm having it in 3.26 - as long as providers that use the setting don't break when they are autostarted anyway (because they are run on an older gnome-shell version), everything will be fine. And in face of flatpak and friends, not assuming that gnome-shell is at the same version as the application does sound like good advice anyway, so there's little benefit in my opinion in waiting for 3.28.
Comment on attachment 359794 [details] [review] remoteSearch: Allow search providers not to auto-start Attachment 359794 [details] pushed as 289f982 - remoteSearch: Allow search providers not to auto-start
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.