From kde-panel-devel Fri Sep 30 23:32:44 2016 From: Aleix Pol Date: Fri, 30 Sep 2016 23:32:44 +0000 To: kde-panel-devel Subject: Re: plugins,caches, startup time Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=147527840304522 On Sat, Oct 1, 2016 at 12:18 AM, Sebastian K=C3=BCgler wrot= e: > On Friday, September 30, 2016 4:23:52 PM UTC Aleix Pol wrote: >> > Nice, I suppose KPackages are a little different to plugins, since the= re's >> > more overhead reading, the package metadata is stored as .desktop file= , >> > which means more conversion costs compared to the binary json that's i= n >> > the plugin binaries. Aleix has recently been looking into converting i= t >> > to json, but that would only save the .desktop to json part, binary js= on >> > is still much quicker to read (the format is pretty close to Qt's >> > internal representation in memory, deserialization is almost entirely >> > I/O-bound. >> >> It's not only about loading from json. Keep in mind that even adding a >> cache we'll be loading each metadata.desktop a number of times either >> way (both using KConfig parsing and KCoreAddons' DesktopFileParser). > > No we won't, the caching code stores/restores a binary json file, > deserialization of that is really cheap, the KPluginMetaData is created f= rom > the json object, which is the cheapest constructor you could think of (it > neither has to go through DesktopFileParser nor JSON deserialization, see > kcoreaddons[sebas/kpluginindex2]/src/lib/plugin/kpluginloader.cpp:283 > > When *creating* the cache, yes, we have to go through DesktopFileParser o= r, > once we've migrated everything to metadata.json, through Qt's JSON > deserialization. The cache will be faster to read in both cases. As I pointed out in this RR [1], that's not entirely the case, because to create an applet we pass the path instead of the metadata tuple (which parses each metadata.desktop file twice). It will have an impact when it comes to listing plugins, but it mostly has an impact because we're in fact caching runs of the DesktopFileParser which is quite inefficient. Furthermore, there's little reason to make tens of listing calls in matter of few seconds and not cache these in-process. Aleix [1] https://git.reviewboard.kde.org/r/129057/