Create Task
Maniphest T14090

Port KPackage away from QJsonDocument::fromBinaryData
Open, Needs TriagePublic
Actions

Description

KPackage makes use of QJsonDocument's ability to convert from/to a binary representation. This is deprecated in favor of using CBOR.

Since I assume the two are incompatible we likely need a migration strategy for existing data

mart added a subscriber: mart.Feb 25 2021, 5:27 PM

perhaps the disk cache could even be ported in normal text json format?

alex claimed this task.Feb 25 2021, 5:41 PM
alex added a subscriber: alex.

This data is only used to speed up the listing/querying of the packages. The files could be recreated using the information that is already on disk. Some actual benchmarks will help to evaluate the situation.

I will look into this once the exams are done.

alex added a comment.Mar 19 2021, 12:59 PM

@mart I used https://invent.kde.org/frameworks/kpackage/commit/8f3313481b33e7401ab994606ba6b71e18b72366 for my benchmarks. There are actually two types of caches, one is the in memory one and the other one the kpluginindex.json one. I cleared the in memory cache to make sure they are newly loaded. @mart is that correctly done?

The results can be found here: https://invent.kde.org/-/snippets/1572

alex moved this task from Needs Input to In Progress on the KF6 board.Mar 28 2021, 9:06 AM
ervin moved this task from In Progress to In Discussion on the KF6 board.Mar 28 2021, 9:12 AM
ervin moved this task from In Discussion to Backlog on the KF6 board.
mart added a comment.Mar 28 2021, 3:56 PM

> I cleared the in memory cache to make sure they are newly loaded. @mart is that correctly done?

yes :)

mart added a comment.Mar 29 2021, 9:18 AM

Also, some general considerations:
back then when measuring the performance gain offered by that index was measurable, but somewhat small anywyas... if the format gets ported we don-t need a migration strategy as the index is not necessary and canbe recreated, but if the on disk index is just killed... i think all considered i wouldn-t be against such a decision

alex added a comment.Mar 30 2021, 9:23 AM

I will do some general investigation/cleanup of the users in the KCMs. The way the KNS signals are handled is very inefficient and we could significantly reduce the amount of times we use KPackage to list all packages.

I am currently working on this and related issues on the KNS framework side. It is good to have anyways and allows us to get a better overview of the usages and we can better assess the performance implications.