From kde-core-devel  Sat Feb 17 11:26:40 2024
From: David Faure <faure () kde ! org>
Date: Sat, 17 Feb 2024 11:26:40 +0000
To: kde-core-devel
Subject: Re: revisiting the sycoca
Message-Id: <6717251.zL2vLDh68u () asterixp15>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=170816912016345
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart4737248.tE8tT7jQ6h"

--nextPart4737248.tE8tT7jQ6h
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
From: David Faure <faure@kde.org>
To: kde-core-devel@kde.org
Subject: Re: revisiting the sycoca
Date: Sat, 17 Feb 2024 12:26:40 +0100
Message-ID: <6717251.zL2vLDh68u@asterixp15>
Organization: KDE
MIME-Version: 1.0

[sorry for breaking the thread, copy/pasting from the archives after re-
subscribing]

On Tue, Feb 13, 2024 at 1:13=E2=80=AFPM Sune Vuorela <nospam at vuorela.dk>=
 wrote:
> 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.

Not exactly (or maybe I misunderstand).=20
ksycoca is a .desktop cache, and what changed in 5.0 was that mimetypes are=
 no=20
longer defined by desktop files so indeed they are not in ksycoca anymore.

And the KParts are now using the Qt plugin JSON stuff so they don't use des=
ktop=20
files anymore (right?).

But the main part still is in ksycoca: all the application desktop files.
And I don't believe this should change; here's why.

One purpose of ksycoca is to find out easily "what are the applications=20
associated with a given mimetype, by order of (user, otherwise desktop-
dependent default) preference". Without a cache, for mimetypes not listed i=
n=20
any preference file, you have to iterate over a large number of desktop fil=
es to=20
find out which ones support it.

Another purpose is to organize the desktop files in a tree that is shown in=
 the=20
K menu (based on Categories and that menu definition XML stuff). Without a=
=20
cache, the performance will be horrendous, won't it?

You can remove everything about "service types" from ksycoca if no plugin i=
s=20
represented by a desktop file anymore, but I would advise against removing =
the=20
cache of application desktop files. IMHO, if you do, you'll end up=20
reimplementing a different one anyway at some point.

> What's the plasma startup performance with and without sycoca on a
> clean user

You're going to move the menu generation code to plasma just to measure tha=
t=20
it's slower? ;-)

> I wonder if we should also try to get David Faure to look at this
> thread.

If it was on kde-frameworks-devel I would have seen it earlier, without hav=
ing=20
to be pointed to it ;). I thought we moved KF tech discussions to k-f-d and=
=20
kept k-c-d for more global stuff like "please review app X before it can go=
=20
into module Y" or other process stuff.

=2D-=20
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

--nextPart4737248.tE8tT7jQ6h
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEU+a0e0XOo+DVt0V3WNDuZIpIs7sFAmXQl/AACgkQWNDuZIpI
s7sfOgf+Pc6dOORhTcsyT9QJCnVRk7H+c+vrK8RbkY1rQ9AaNFgbkWrGHw9xv3wk
StpFXd6J/z1h208Znd95upEiHaa3kos0xBUZs/aSYZzMUlfEH4LOjGZOnmZA07i1
Ak+4915eeNbxnb4Mpdg+Vtao8EA7ZfQqWGza3eDiKHMSf+9CyHHtZq9k+N+9FWnr
Mcj7of9hpEYtvEg7EGXpvbnmPO7/vMMcs38HW7srBHt2YBbZpCbwZLmNGC0G7yCB
JZ41C0frj4cbh27RMWurkSI5L/tWyl8MhdvtBGBiXCbVzoHoYJJYgfhgU3XsHFJK
zESPAJB75dgZjNFJHjeHa3IqbsoPTw==
=k5tm
-----END PGP SIGNATURE-----

--nextPart4737248.tE8tT7jQ6h--