Cache the calls to windowUrlFromMetadata, because it can be called quite often, for example with the vivaldi browser started, and it usually calls KServiceTypeTrader::defaultOffers that also involves I/O.
CCBUG: 342056
CCBUG: 358231
hein |
Plasma: Workspaces |
Cache the calls to windowUrlFromMetadata, because it can be called quite often, for example with the vivaldi browser started, and it usually calls KServiceTypeTrader::defaultOffers that also involves I/O.
CCBUG: 342056
CCBUG: 358231
Browse with vivaldi browser in private navigation.
No Linters Available |
No Unit Test Coverage |
Interesting. I'm curious as to why it calls those functions that often in the first place while copying files.
My guess is that it is used to fill the task completion in the task bar, but is only a wild guess.
The progress display is completely independent of libtaskmanager. Can you disable it (Uncheck "Show application badges and progress" in task manager settings) and see if that changes anything?
What I've noticed is that with the first version of the patch,
every time I changed konsole tabs, saved a file in kate, the appDataFromUrl (missed the cache) was called.
After not removing that data from the cache, with an appdata of 0.04%, the calls to appDataFromUrl are far, far away now (in the 0.01%) along with the KService... calls.
Does it have unexpected consequences? I don't know the answer, but I've not noticed them.
I'll check disabling "Show application badges and progress" (without this second version).
every time I changed konsole tabs, saved a file in kate, the appDataFromUrl (missed the cache) was called.
Whenever NET::WMVisibleName changes, both caches are evicted. It might be worth checking what's more expensive to create, the KWindowInfo or AppData and then use one or the other depending on it, e.g. use the KWindowInfo for the visibleName and don't nuke the appDataCache when that changes, or so. I'm not very familiar with that codebase.
libtaskmanager/xwindowtasksmodel.cpp | ||
---|---|---|
330 | However, just *not* killing the cache would lead to DisplayRole, AppId, AppName, GenericName not updating as these are taken from appData in data() |
In https://phabricator.kde.org/D9840 I noticed a high i/o and cpu usage
when using the vivaldi browser, opening 10 tabs just caused a 40% cpu
usage. Now, opening 10 tabs or more is bellow the 0.03%.
I know now why it is calling windowUrlFromMetadata.
Because unlike firefox and chromium, with sub processes using the same executable but with parameters, the vivaldi sub processes are called vivaldi-bin, and there is no .desktop file for that executable name. As soon as I've manually created a .desktop file for vivaldi-bin, plasmashell cpu became normal without the patch. With the patch, there is no need for the .desktop file.
libtaskmanager/xwindowtasksmodel.cpp | ||
---|---|---|
516 | const auto url = ...; note the space after the = |
Implement only the windowUrlFromMetadata cache.
It avoids a 100% plasma cpu usage when using vivaldi in private navigation.
This patch doesn't make any sense. It's setting up a cache for something computed from data that's subject to change, and it's never evicting it when that data changes.
To make it right, should it also be wiped in XWindowTasksModel::Private::windowChanged?
Or perhaps is it better to try to create that cache in KServiceTypeTrader?
That will be the right place, reading from disk is always costly, it will be better to make service parsing on file changes otherwise to read from cache.