https://bugs.kde.org/show_bug.cgi?id=434877
--- Comment #36 from Mark <mark...@gmail.com> --- (In reply to Méven Car from comment #35) > I think this shows we shouldn't use vmaps to compute memory usage. > Albeit the best data we can get, we should either lower its frequency update > or use another method altogether. > > https://invent.kde.org/plasma/libksysguard/-/commit/ > 1f48d7e9c420a40372b7ecfaf20d99d2e876168c impact should be negligible. I just went through a bit of libksysguard and ksysguard. And gave up. In the past i would've spend days (weeks even) profiling this, finding the bottleneck and finding ways to solve it. Now... I don't see a point. The current "plasma-systemmonitor", while visually good looking, has become a heavy program to run. It's gui "feels" sluggish (think of how sluggish java apps feel, that's how i experience plasma-systemmonitor). And making changes has become close to rocket science because the codebase of this and libksysguard are huge for what they do. Also, did we "need" a redesigned ksysguard? I liked the old look too (which was refreshed!). I also tried to recompile the last version of ksysguard (the gui) but that is impossible as ksysguard (the library) doesn't work anymore due to some qml qt6 only thing (fails in the cmake step). The solution you propose (extending the update frequency) makes the whole app even more useless. When i open a system monitoring tool i want to see what's going on. Setting that update to 2 seconds effectively smooths out short spikes that you would have seen at half a second. That's useless. My unsolicited, and perhaps a bit harsh, advice: - Go back to a situation where it was usable. Meaning revert to ksysguard from KDE 5.x and set aside plasma-systemmonitor because it is obviously not suited for the task it's meant to serve. ksysguard had less issues so back to a point from where it's better at least. - Meanwhile, really thoroughly think about plasma-systemmonitor. The fact that it has panels/pages/edits is "awesome"... but come on, do we really need that in a system monitor? That's a lot of extra functionality that is just wasted for plasma-systemmonitor. It would be a thousand times better suited for kmail for example. - Simplify the codebase. A LOT! Take btop as an example. - Aim to have a 500ms update frequency at barely any cpu usage (btop can while still being super flexible. There's no reason why plasma-systemmonitor can't) -- You are receiving this mail because: You are watching all bug changes.