Improve performance of overview search on systems with slower disks
Feature summary
I got a notification about https://bugzilla.gnome.org/show_bug.cgi?id=785380 when Bugzilla shut down, and wanted to preserve this feature request, since as far as I know it's still an issue on systems with slow disks! GNOME running smoothly on that sort of system is important to me personally, so I'd be interested to help if there's something I can do to help move this forward, though I don't know much about Tracker.
(If this is not specific enough and it belongs more on a roadmap or something like that, feel free to close it.)
Some steps were already taken as part of that Bugzilla issue, but there was still the rest of the plan outlined which I thought would be worth preserving.
Here are relevant parts of the discussion copied from the Bugzilla issue:
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.
[...]
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.
[...]
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.
- those with really dynamic data (Calculator), probably a special case amongst the special cases
(This is all research from Bastien; cc @hadess)
How would you like it to work
Here is Bastien's original proposed roadmap:
-
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 -
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
Relevant links, screenshots, screencasts etc.
- 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
- Back when I worked at Endless, this is how we solved the problem specifically for offline content apps, by creating a joint search provider: https://github.com/endlessm/eos-knowledge-services/blob/master/search-provider/eks-search-provider.c