Re: revisiting the sycoca
On 2024-02-13, Harald Sitter wrote: > Do you have a testing plan in mind? Not a dedicated one, no. But assuming your analysis is mostly correct, something along the lines of - What's the plasma startup performance with and without sycoca on a clean user - If much slower, try isolate which of the 3 parts are responsible - What's the startup performance if a user has done modifications like menu changes and user-environment installed apps/desktop files [a] - What happens when a user adds their own mimetype additions ? That could also be loading a folder with such files in dolphin or a 'save /open'-dialog I'm assuming this is mostly disk intensive operations, so a slow disk (spinning metal) is probably a good idea for that. I wonder if we should also try to get David Faure to look at this thread. /Sune [a] Isn't this even more likely in the world of flappacks and snacks and appimages and snaps and flatpaks and such
Re: revisiting the sycoca
On Tue, Feb 13, 2024 at 1:13 PM Sune Vuorela wrote: > > On 2024-02-08, Harald Sitter wrote: > > It occurs to me that we should ponder sycoca a bit. > > > > Currently the sycoca contains 3 types of caches: > > At some point I remember David Faure, iirc as part of his QMimeType > work, removed part of sycoca, but left the remaining bits as a per > user cache *because* we allow the user to modify things. > > I don't know how much of it is still relevant, but I do think we should > be testing it, both on modern ssd systems, but given our occasional > marketing drive about keeping older systems running, especially also > on older systems with a spinning metal disk, rather than a bit handwavy > "This is probably going to be fine" Do you have a testing plan in mind? HS
Re: revisiting the sycoca
On 2024-02-08, Harald Sitter wrote: > It occurs to me that we should ponder sycoca a bit. > > Currently the sycoca contains 3 types of caches: At some point I remember David Faure, iirc as part of his QMimeType work, removed part of sycoca, but left the remaining bits as a per user cache *because* we allow the user to modify things. I don't know how much of it is still relevant, but I do think we should be testing it, both on modern ssd systems, but given our occasional marketing drive about keeping older systems running, especially also on older systems with a spinning metal disk, rather than a bit handwavy "This is probably going to be fine" /Sune
Re: revisiting the sycoca
> All in all I am not convinced we still need the sycoca As you noted it's 3 different things. I suggest we tackle it as 3 different tasks. The mime apps part we should be able to drop silently without any issue. The menu and desktop files are still needed by krunner and plasmashell and xdg-desktop-portal. I don't think an external cache is problematic here, it works. It could be done differently, but we're just moving the problem about and I don't think there's any immediate savings here. What we should be looking at as a first step is splitting "what applications need" from "what do system services need" and making sure these are separate and covering the right things. Apps seem to mostly use serviceByDesktopName that doesn't need to be backed by a cache, at worst we have to stat 4 or 5 folders. I propose we replace that with a lighter desktop file wrapper higher up in the stack (Kconfig?) and port those instances in apps. Or maybe it should be backed by some relevant portal call. David
