GNOME Bugzilla – Bug 692850
The Gnome-system-monitor uses a lot of system resources while monitoring system resources
Last modified: 2013-06-28 19:41:36 UTC
It depends a lot on the update interval, however, after perusing and modifying the code, I've discovered the issue. The interval timer is firing 10 times more than useful, collecting statistics too often, for the resource view.
Created attachment 234787 [details] [review] patch cpu utilization of gnome-system-monitor been "bugg'n" me for a long time. Finally did something about it. ;)
Oh, You can keep it looking like the original system monitor by reverting NUM_POINTS to 60 in load-graph.h
Setting the NUM_POINTS to 60 will make the scrolling "jump" because I've removed the smooth scrolling code. By adding more data points the illusion of jumping is somewhat removed. The smooth scrolling is why the timer was firing 10x too often. Which the original author did a very nice job, except the CPU utilization is a bit excessive.
Created attachment 234877 [details] [review] better patch There's a bug in the first patch. +2 on NUM_POINTS was skewing the chart rendering. Also, outside of the virtual machine, I noticed a significant performance enhancement with ciaro_line_to, opposed to ciaro_curve_to so that is the default for non-stacked. W/the bug fix this does look a lot more like microsoft's taskman, that' wasn't my objective -- performance enhancement is the objective. +10-% cpu utilization is absurd for gnome-system-monitor. Makes you want to opt for something different. I like htop/top, etc..., gnome-system-monitor is the default. Let's have it adequate performance.
Review of attachment 234877 [details] [review]: Thank you for your work, improving System Monitor performance is indeed a good objective, but I would have some objections: * 5x the history would be good * By removing the "excess code" you loose the smooth curves and smooth scrolling, which is not something we want, refreshing rarely makes system monitor look like if it was lagging - experiments show that smooth curves and smooth scrolling properly implemented can achieve the same performance improvement, like you have achieved by eliminating them (see bug 636343 on uber-graph, a library having an example application just like system monitors Resources tab - it really should be integrated, but unfortunately I do not have enough experience to do it, and I don't have enough time to experiment with it, I have spent some afternoons already with this, but gave up, maybe I'll try again) Any help there is welcome on integrating uber-graph, that would really help. * Your patch also breaks the stacked area chart drawing, somehow the stacked area chart does not start at the right place and always end with 0 values, which is not the case without the patch.
Review of attachment 234787 [details] [review]: Marking as rejected, as the second patch attached to the same bug does the same thing, and should obsolete this.
Remarkably, uber-graph uses approximately the same amount of cpu as my patch, tho my patch does plot 5x as many data points. I didn't expect that to work out to be quite so similar. I haven't looked at uber-code, but I had considered that type of implementation. Uber would probably be better for 10x-20x datapoints. Add 5x data points removes the ability to draw smooth curves. Since line_to uses less cpu than curve_to, I believe its the slightly better option. The CPU difference is negligible though, based on limited comparison. I tried 10-15x more datapoints, but that had a negative impact on cpu utilization. The original code draws to datapoints outside the visible graph, which is why my patch causes visible issues with the stacked graph. That could be rectified by returning to drawing beyond the extents of the visible graph. I don't believe it needs to be drawn as far out of the visible range as the original. However, by drawing outside of the visible range, you return to not-quite real-time data being display. Which is something I had hoped to avoid. Starting the graph, then not seeing any data plots for a few seconds is somewhat frustrating, IMO.
I have tested uber-graph with 5x (300) datapoints, and the CPU usage is still shown as 0%, and it's drawing smooth curves. I'd rather not give up the curves, if it is possible to draw them at such low CPU usage, even if drawing lines is cheaper (as you also said, the difference is negligible), as drawing lines would be a regression, even now some people are asking for smoother graphs, falling back to lines would be a regression for many people.
*** This bug has been marked as a duplicate of bug 636343 ***