https://bugs.kde.org/show_bug.cgi?id=521757
--- Comment #4 from cwo <[email protected]> --- (In reply to bugs.overpass613 from comment #1) > Maybe i've found the Root cause of the CPU/SQLite thrashing, found via > heaptrack while > investigating a related plasmashell freeze/leak: every call to > KActivities::Stats::ResultWatcher::resultRemoved() re-runs a full SQLite > query from scratch (ResultModelPrivate::fetch() -> new ResultSet -> > QSQLiteResult::prepare/reset) instead of updating incrementally. In a > 14-minute heaptrack session this call chain alone accounted for > 139051509 allocation calls. Thanks for investigating. I'm not too famliliar with the implementation and possible optimizations here. resultRemoved() should only be called when a result is removed from the database, and ResultModel should only fetch if it needs more data now - it keeps a local cache of the results, and only requests more from the database if one of the removed files was currently in the active set. Results should only be removed from the database if something requests it to be forgotten, or if new files are loaded into the model and these files no longer exist. I've tried running this under heaptrack myself, even manually forgetting things from the database, and the allocations involved with resultRemoved were basically negligible. So the primary question would seem to be why it keeps emitting resultRemoved so often that this would cause problems. Could you use dbus-monitor or bustle (this one is likely easier) to investigate whether there are a lot of removals on org.kde.ActivityManager.ResourcesScoring, and what kinds of files are being removed? Maybe there is something that keeps adding and removing things, or some other systemic issue. -- You are receiving this mail because: You are watching all bug changes.
