https://bugs.kde.org/show_bug.cgi?id=434877
--- Comment #14 from Arjen Hiemstra <[email protected]> --- (In reply to Riccardo Robecchi from comment #12) > Arjen, I think I have understood why there is excessive CPU usage and I have > a proposal on how to fix it. The problem is that System Monitor (and > KSysGuard as well, though to a less extent) simply poll the information too > often. The difference between Plasma System Monitor, which uses a lot of > resources, and GNOME System Monitor, which is quite efficient, is that the > latter does not update the data as often, thus using much fewer resources > and being much lighter on the system. It is my conviction that by reducing > the amount of times the data is updated, a satisfactory balance can be > achieved. > Currently System Monitor updates multiple times a second, which is overkill > for any practical purposes: nobody needs to see the CPU graph going up and > down with such precision, one or two times a second would be more than > enough. As far as I understand this, this would involve basically any other > application and widget that relies on this features because this is all > managed in the KDE Frameworks? Do you reckon reducing the update rate would > be feasible? > Let me know. Thanks. So there are a few things here, one is global information, like CPU usage, network usage and sensors. These are handled by ksystemstats, which runs at an update rate of 500ms. This is passed over DBus to plasma-systemmonitor, which then gets change signals and passes this to sensor objects that record these changes and allow the UI to do its thing. In some cases, like line charts, there's a data source for the chart that requests data from these sensor objects on a regular interval, so that we can display a continuous line chart. Not all these timers run in sync, so you may end up having some staggered updates, but no individual chart should update more frequently than every 500ms. There is also a setting to reduce how often a chart updates. This is only client side, but reduces how often redraws happen. There is another part, which is the more relevant part here, which is the process data which is provided through ProcessCore. This runs on a timer of two seconds and then reads a whole bunch of system files, parses them and updates all the relevant process files. There's one tricky file in here, which is `/proc/$PID/smaps_rollup` which provides the most accurate memory usage measurement of a process, in the form of the "proportional set size" value. Unfortunately, it also turns out to be a slight bit of a minefield: when opened, the kernel goes through the entire memory mapping of a process to accumulate the needed values. This turns out to be a rather expensive operation, especially when doing it for all the running processes. This is actually the main source of CPU usage you're seeing. I have done some work the other day on being able to disable this part of the process data collection, by disabling the "memory" column from the UI. The library parts are all there, but right now the UI in plasma-systemmonitor requires the memory column for the details pane, which I do not have a solution for yet. Once that is done, you could disable the memory column and replace it with something like "private usage" to get rid of most of the CPU usage. -- You are receiving this mail because: You are watching all bug changes.
