GNOME Bugzilla – Bug 319682
Add per-process CPU history usage graph ("sparklines")
Last modified: 2018-05-22 11:58:03 UTC
I'm about to attach a first pass at some code which implements a "sparkline" GtkCellRenderer subclass, and a patch to procman which uses it to add per-process CPU % history. The patch isn't done yet, and suggestions are welcome on how best to integrate this. Federico was suggesting on IRC that this could be implemented for memory usage as well, so that you can see trends on memory usage per-process (e.g. to quickly spot memory leaks by visual scanning)
Created attachment 53849 [details] new GtkCellRenderer subclass implementation
Created attachment 53850 [details] header file for the above
Created attachment 53852 [details] [review] Initial version of patch to wire this up This is currently a bit of a mess, but I wanted to get feedback before progressing further with this. Something I tried to implement which isn't working yet is to redefine the concept of an "Active Process" as being one which has had activity in the period shown in the sparkline, also, to redefine the sort order so that %CPU is sorted by the areas under the graph (currently processes leap around a bit too much when sorted that way)
Created attachment 53853 [details] Screenshot of this
Cell renderer has a "filled" boolean attribute which is set for the screenshot; I think this makes sense for this case for a resource usage case (since you can visualise cost as the area under the graph); if you set this to false you get a simple line. I think I've slightly messed up the clipping; there's meant to be a little red dot showing the current state, right-aligned. The cell renderer takes a GArray of double, assumed to be in the range 0.0 - 1.0
CCing federico and duffy as both have expressed an interest in this. Ideally I'd like the new cell renderer to land in GTK, but obviously it will need some more design and usage in other situations (e.g. gnumeric, network interface selection, evolution????)
Thanks. I had put this on my todo. Putting the graph in the CPU col looks weird to me. I would have make per-process-CPU/Memory/Whatever-usage graph on demand. I'd like to keep g-s-m as light as possible. Your changes to src/proctable.c make updates much more expensive. What about putting these kind of graphs to a new window, just like memory maps or openfiles ? Then you could use the same graph widget than the resource view.
I think the value of embedding the graphs in the process view is that that's where the per-process information is listed. I'd have it as an option for that view, rather than a separate view, and enable it by default. To use Tufte's jargon, the column then becomes a set of "small multiples" where the values are easily compared. Is gnome-system-monitor aimed purely as a graphical replacement for "top", or are there other goals? Who is the target user, and what are they using it for? My primary use of sparklines is when I'm wondering why my CPU spiked 10 seconds ago and I only just got control back over the UI (by which time the constantly shifting CPU stats aren't helpful - what if the process isn't around anymore?)
Fedora's graphical tool to manage Xen VMs implements CPU usage sparkline. http://people.redhat.com/berrange/virt-manager/screenshots/host-summary.png It would be nice to have in GNOME System Monitor.
Any movement on this? I would find it particuarly helpful in system-monitor
I'd like to also see this implemented. Please consider its integration
I'd like to, but in this way. On a 1GHZ CPU, system-monitor alread eats to 25% CPU ... i'm not proud of it.
This is a great feature, I'd love to see it too, so I'll take a look at getting the cpu consumption down. This will involve profiling the renderer, ensuring that only on screen cells are rendered and maybe various other tweaks. This will need testing on intel, ati and nvidia as the 2D performance differs drastically on each. In more general terms GSM needs profiling. This will probably have to wait until after 2.22 is out. So I hope to get this in by gnome 2.24 :)
Have a look at how much CPU the resources tab takes :/ The proctable already uses a lot of CPU (mainly because of the writable memory column), i'm really concerned about CPU usage, it should stay < 5% on a 2GHZ CPU.
One profiling thought: how much CPU is taken on the rendering, vs the gathering of the data? One way to measure this might be to render it with the CPU usage of every process hardwired to 100%, rather than reading /proc
Forgot to add: this would involve hardwiring all the data; is it possible to supply a mock implementation of the process data, so that you have a hardcoded list of e.g. 20 processes. What does the CPU load look like then? (using top or something else to measure gnome-system-monitor itself, of course!)
Created attachment 110687 [details] Updated version of sparkline cell renderer (cleaning out dead code)
Created attachment 110688 [details] [review] Updated version of patch I've updated the patch, from the old one against CVS C code to the SVN C++ code (pre the gio merge since I don't have that handy on this machine); so this is against svn r2399. Updates are an issue; the cell column only gets redrawn when the CPU value changes, not when the array of values scrolls (so you get weird-looking updates when mouseovering idling processes). Fixable, but not sure of performance impact. Perhaps issue a call to gtk_tree_model_row_changed when the array scrolls, but only if the scrolled value != new value (if that makes sense)
Removing assignee, as there has been no progress on this in the last 4 years.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-system-monitor/issues/5.