search

hakandundar34coding / system-monitoring-center

Multi-featured system monitor
GNU General Public License v3.0
905 stars 83 forks source link

In process tree view, sorting by CPU usage does not allow finding which processes are using the most CPU time #200

Closed AlexFolland closed 1 year ago

AlexFolland commented 1 year ago

In the process list when in tree view to show which processes have which parent processes, sorting by CPU with the CPU column is very difficult to determine which processes are using the most CPU usage at any given time. This is because the total CPU usage of the process' children is not shown, so the process shows "0%" and if not expanded, the child processes' CPU usage is hidden completely. This also seems to cause the sorting to fail, meaning sorting by CPU usage doesn't put the highest-usage processes at the top of the list. The processes with the most CPU usage are hidden away, way down the list and inside collapsed nodes.

In these 2 screenshots from System Monitoring Center, we can see that even though systemd child process sddm has child processes with more CPU usage than processes above it, sddm is way down the list and nowhere near the top of the list, and its CPU usage is shown as "0%" while collapsed, hiding the CPU usage of its child processes.

image image

Compare this to ksysguard, where sorting by CPU usage in the tree view allows the user to very easily find exactly which processes are using the most CPU time by simply expanding the top-most processes.

image image image

In ksysguard, processes with actually 0% CPU usage but child CPU usage above 0% are shown with their total CPU usage in an italic font, while processes which are contributing the CPU usage above 0% themselves show the CPU usage without italics. This intuitively shows which processes are actually using the CPU time, and which parent processes need expansion to see their CPU-using child processes.

Also in ksysguard, it is easy to find the exact CPU usage by the parent process by simply hovering over the CPU usage column and checking the statistics there, as shown in this screenshot.

image

Behaving like ksysguard in this way would allow sorting by CPU usage to easily see which processes are using the most CPU time, even when the child processes don't give a clear indicator of what their parents are from their command lines.

hakandundar34coding commented 1 year ago

There are options for recursive CPU, Memory (RSS) and Memory information.

A screenshot:

smc_processes_menu

Additionally, process CPU times (different from CPU usage (percentage)) can be shown.

Detailed CPU times (system, user, are shown by using process details window. You can open it by double clicking on a process.

An example:

smc_process_details

There may be improvements for CPU usages (system, user, etc.).

AlexFolland commented 1 year ago

Ah, that does exist. Thanks! I think that column should be enabled by default.

That being said, System Monitoring Center uses a lot more CPU than ksysguard while doing the same thing, even with the new highest-CPU-process feature disabled. I think the recursive CPU usage column should be enabled by default, but if it's not just because of performance, it may be worth looking at what ksysguard is doing to be so lean and display the exact same information.

hakandundar34coding commented 1 year ago

Enabling columns that contain recursive label increases CPU usage. These columns will not be enabled by default because of this reason. There may be performance optimizations for lower CPU usage when these columns are enabled. Python is slower for several operations when compared to the languages such as C, C++. CPU usage may not be as low as ksysguard even after optimizations. I have not used this software before. I have very limited information about it.

Additionally, SMC does not read some files (for getting performance information) directly. This is required for Flatpak support. But this also increases CPU usage. Using two different ways for reading files for Flatpak and non-Flatpak versions requires very much development time. There would be more code. There may be more bugs.

You can use non-Flatpak version of SMC for lower CPU usage. Currently, SMC is not added to a a lot of repositories. They may not be updated very frequently.