[theHamsta]

They mentioned that the culprit for those additional load times was loading all the search backend for their application launcher which they deferred to the moment when there was actually the first search query (still shouldn't take multiple seconds)

[Topfi]

Thanks for the clarification. Opinions will differ, of course and I cannot say whether the time required is justified or calls for optimizations, but personally, I view that moving this to the first search query is less elegant than having it happen during the initial start, when users are more accustomed to waiting a bit longer. With the new setup, the initial query will be less seamless than future ones at a time when the user is actually trying to accomplish something, leading to a degraded experience as far as I am concerned. But, as per usual, distros will make differing choices in this regard, and we shall see what ends up being shipped as the default in most cases.

[bee_rider]

I’m surprised they wouldn’t go for “kick off it off early in the process but allow the desktop to load without it” instead.

[starkparker]

Baloo (KDE) and Tracker (Gnome) are typically the first things I disable on any Linux desktop install that requires either of them. Tracker is hot garbage and a pain to disable. Baloo at least is granular and configurable enough to turn off file indexing without breaking search on the entire DE.

[j1elo]

I'm surprised they didn't go to a more clever solution such as "start loading it as soon as the most core components have already loaded, and CPU usage falls below 30% during 3 to 5 consecutive seconds".

That'd seem to me like a sweet spot between what was before (making the whole system startup slower), and what you mention will be now (probably making the first search to load noticeably slower).

[TillE]

With modern hardware and OSes the ideal answer is typically to run non-essential tasks exclusively on efficiency cores. So you leave the performance cores free to handle stuff that the user immediately cares about.

[viraptor]

If anyone wants to play with that, the "uclamp" interface is the "nice" that affects the scheduler / placement / energy use. Pipewire got a patch recently to keep the requested power low https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/70...

[jancsika]

> loading all the search backend for their application launcher

Wasn't the whole initial selling point of systemd parallel startup?

Why can't this launcher thing just get set to start up as early as possible, with lowest priority, and be set to not block initialization of anything else?