Well, we can't use this as a drop-in replacement as it's currently Linux only according to the github readme. but I'd accept a patch that enables this for Linux.

The uber graph implementations where less than perfect. The proper design went into perfkit, at https://github.com/chergert/perfkit/tree/master/perfkit-profiler. Sadly, it is quite tightly coupled to perfkit.

The important parts are:

  perfkit-profiler/ppg-rt-graph.c
  perfkit-profiler/ppg-renderer.c
  perfkit-profiler/ppg-renderer-line.c
  perfkit-profiler/ppg-visualizer.c
  perfkit-profiler/ppg-visualizer-simple.c
  perfkit/pk-model.c
  perfkit/pk-model-memory.c

As you can see, it's significantly over-abstracted for the use of gnome-system-monitor. I can look at ripping it out into something smaller, but I wont have the time for at least a few weeks.

I’m afraid not the graph drawing is consuming CPU, but updating the process list. A simple experiment to check this: open top to monitor System monitor CPU usage (kindoff funny  ), and change the processes to view from All processes to My processes then to Active processes. As the active processes list contains less processes than My processes, GSM consumes less CPU when set to show only active processes.

But this is only my guess, please mention any evidence you have to prove that the resource-consuming stuff is the graph drawing.

Easy enough. Use "top" to measure. The "My processes" list uses 5% CPU, the "All processes" list uses 5% CPU too. As soon as you switch to the Resources (graph) tab and let it sit there until the graph is filled, it jumps to 18%+ CPU usage.

This is on a Core2 Quad (Q9300) by the way. On a weaker machine, numbers will be even more impressive.

Note that you must start with the process list, not the resources tab. As soon as you display the resources tab, even if you switch back to another tab, the cpu usage will continue because it keeps updating the graph.

@Jean-François Fortin Tam: Fair enough, I did not wait until the graphs get filled. With the graphs filled, I also get around 16% (Core2 Quad Q8300). However for me Active processes top shows 2-4% CPU usage (2-3 processes shown), My processes shows 20-30%, All processes uses 30-40%. So these are two different issues (this issue for Resource graphs CPU usage, and another one for the Process list CPU usage).

I'll try to profile the code to find out the bottlenecks in these spots and check whether it's really the graph drawing or processing the information retrieved from libgtop, or something else.

I have profiled GNOME system monitor using callgrind, and lot of time is spent in cairo_curve_to (to draw the smooth bezier curves with cairo), but the exactly same method is used to draw the bezier curves in uber-graph and perfkit profiler renderer, so we can only tell whether there is a difference if someone implements a patch for using ubergraph/perfkit profiler renderer.

As an experiment, I have replaced cairo_curve_to with cairo_line_to (and the graphs loose their smoothness caused by drawing the beziers) and system monitor usage falls from 16% to 1-3%.

If you aren't going to read the code I provided that shows how to solve this problem, please at least read the write-ups[1][2][3] that talk about the evolution of incrementally speeding up this type of widget. It is *significantly* faster than GSM, while also at least doubling the framerate. I have no problem doing 60 fps here with less CPU than GSM.

[1] http://audidude.com/?p=404
[2] http://audidude.com/?p=470
[3] http://audidude.com/?p=527

@Christian Hergert: Actually I have checked the code, and seen that it also uses cairo_curve_to which looks like something playing a major role in eating CPU time. I didn't say it will not improve system monitor, only that we will see the benefits only after it's integrated in GSM, which seems like will take time (both on the perfkit side to split out the charting code as you have mentioned and on the GSM side to integrate it).
And sorry about not reading the write-ups, I would've read them, but unfortunately I'm bad at searching and the obvious search queries (realtime graphs gtk) did not work, showed only seemingly irrelevant pages at first sight, and so did the cairo examples site (http://cairographics.org/examples/). Thanks for the links anyway, an intesting read, I hope someone (or I) will have the time to integrate it into GSM.

@Robert Roth: The first thing, would be to avoid having to draw the lines on every frame. That right there will be a 15x improvement on a 15 FPS animation. Doing this will also let the frame-rate go up closer to 60 FPS for smoother animations without significant overhead.

The ring-buffer stuff was nice, but will be much less than the above.

[Adding missing "QA Contact" entry so system monitor bug report changes can still be watched via the "Users to watch" list on https://bugzilla.gnome.org/userprefs.cgi?tab=email when the assignee is changed to an individual.]

I have just checked the system monitor demo from https://github.com/chergert/uber-graph, which runs blazingly fast (on my quad core pc system monitor resources graph uses around 20% cpu in top, while the uber-graph system monitor data uses at most 1-2%), so it's clearly worth using uber-graph. 
A great idea Christian Hergert, the uber-graph author had in terms of UI, to be able to hide/show color selectors for a given graph by clicking the chart. This will help users see more detailed chart, use vertical space optimally, but still have color selection and labels handy if they need it.

John Stowers and I have been working on making this a real library that can be used. I still need to bring over some work from the now defunct perfkit effort I did. Once the library is ready, I can work on some patches for this.

@chergert: any update on making uber-graph a real library, which could be used here?

*** Bug 692850 has been marked as a duplicate of this bug. ***

*** Bug 550708 has been marked as a duplicate of this bug. ***

*** Bug 568985 has been marked as a duplicate of this bug. ***

Ok, I see uber-graph became sortof part of libdazzle, so let's use the graph widget of libdazzle. Updating the title accordingly.

One thing I never finished in libdazzle that I had prototyped in uber-graph was the ability to do incremental updates to the backing surface (so you only draw 1-3 data points for every new collection).

So currently the code draws a new graph for each collection (generally 1-2x per second depending on your needs).

Further more, we update on the frame-clock, so reaching 60fps is possible for a smooth graph. But this also comes with additional CPU usage since you wake up on every frame.

Further more, I see even more usage on Wayland than I did on Xorg where we got nice GPU-side surfaces which were fast to 2d blit.

I my ideal long term goal would be to rewrite this as a GL/vulkan shader, and only upload the series of datapoints that need to be drawn (as texture data).

-- 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/31.