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.

Reply via email to