GNOME Bugzilla – Bug 710332
High CPU load when timer or stopwatch is running
Last modified: 2021-06-01 22:44:15 UTC
I'm running last GNOME (3.10.1) with Archlinux 64bits Here is my issue: http://i.imgur.com/Efw0qrc.png I don't think it is normal that a simple timer takes so much CPU ? As gnome-shell and X also get a high consumption, I suppose that this is the animation which leads to such a load. Maybe there is something to improve, because I don't think a simple timer must lead my laptop fan to switch on. Thank you!
Created attachment 259030 [details] screenshot of the high cpu load when using clocks I also notice the same problem with the high cpu load.
the drawing code uses the proper gtk api to draw as efficiently as possible (Gtk's frame clock etc). Whether this is really efficient or expensive largely depends on many components on the underlying stack (e.g. if the compositor supports syncing draws, the X server version, the driver version, cairo library version and so on). I hope that bugfixes and optimizations in all these components will appear soon. From the clocks side the alternative would be to completely rewrite the drawing in opengl, but that's completely out of scope.
It's indeed very suspicious, I can partly reproduce it, for me the cpu loadage remains about 30% for one unit. I do not believe however that drawing requires that much, it must be something else. just pointing to the sky ))) do we need to determine the diameter with calculate_diameter() every time on draw?
or maybe it's due to the add_tick_callback, which is too frequently
I'm also seeing this, and I also suspect you're asking the thing to refresh too frequently. Currently, it will eat batteries alive. Look at it in powertop and you'll see the thing causing hundreds of wakeups. I couldn't quite figure out out stopwatch.vala or timer.vala, but it seem to be adding a glib callback thing that is effective immediately and repeatedly instead of being updating on a regular time interval? If so, that's spamming the UI toolkits and no amount of upstream optimization is going to compensate doing "too much work". I'd say there's no reason to update the UI more than 60 times per second. You may also be able to get away with 10-20 times per second (with a regular update timer that goes off every 50 or 100ms for example).
Hello, such high CPU load is overkill. I also suggest looking for refresh (redraw) rate. If you switch to another workspace in Gnome then CPU load goes down which suggests that it is related to window redrawing. Rewriting app in OpenGL wouldn't help as long as you redraw window as many times as possible.
Let me repeat what I said in comment #2: we are using the proper gtk api (Gtk frame clock), this ensures that our redrawing code is only called at the monitor vsync rate, or when that is not supported, at a fixed rate of about 60Hz or something like that. If we are still using too much cpu, then there are the following possibilities: 1. there is a bug in Gtk Frame clock that makes us redraw more than necessary 2. there is a bug in the drivers and/or xserver that confuses gtk's frame clock 3. there is a bug in how we use the frame clock 4. we are doing everything correctly, but drawing a full frame in plain cairo is still too slow/expensive and we need to rethink all our drawing to either find some optimization and/or change drawing strategy (e.g. use GL) I think 1 and 3 are very unlikely. 2 is possible and it would be interesting to check if people observing this have a common hardware or software stack. 4 is probably true, help in profiling is more than welcome
I don't know howto profile Vala application so here is output of strace for two cases for version from git tag 3.10.1 (same as binary pkg on my system). 1) run clockwatch for ~5 minutes on current desktop 2) run clockwatch for ~5 minutes on other desktop syscall % time seconds usecs/call calls errors total 100.0 0.196785 480077 213025 100.0 0.049933 45264 15910 poll 91.47 0.180007 1 147777 0 86.72 0.043303 3 12392 0 recvfrom 4.92 0.009677 0 272519 211898 3.88 0.001937 0 19277 14799 writev 2.03 0.003991 0 49674 0 1.43 0.000715 0 3274 0
Created attachment 269315 [details] Two full strace logs (line by line)
CPU load goes down if you switch to different tab (from Stopwatch/Timer to another).
Created attachment 269733 [details] perf
Output from 'perf' tool shows that main cost comes from libgtk3 (41%) and libcairo (14%). I don't know howto get their symbol name.
Comment on attachment 269733 [details] perf perf.hist.1 and perf.hist.2 shows zoom on first two items in perf.hist.0
Created attachment 269735 [details] perf
I have 20..30% CPU load in Gnome Shell and 10..15% in Mate/Marco (Gnome 2/Metacity fork). (x86_64, Fedora 20) So in Gnome Shell running Timer takes twice as much CPU than in other WM/DE.
Do you know if the frame sync clock should be used on Fedora 20 with GNOME 3.12 installed form COPR? Is there a way to make sure it is being used?
GTK+ ships with a video-timer testcase in tests/. It also draws a continuous animation driven by the frame clock. It would be instructive to compare the wakeups and resource use between it and gnome-clocks.
Commenting out the label text change in the stop watch brings the resource consumption down quite a bit. Running with GTK_DEBUG=updates tells the story: without the label changes, there's no red flicker, but with the label change, you see a constant flicker at the right edge of the window, indicating that setting the label triggers a full size allocation of all widgetry, for every frame.
Until gtk grows a way to avoid a full relayout in this case, a way to avoid the cost would be to stop using a label here, and instead draw a pango layout manually.
This is still an issue on Gnome 3.16. Please bear in mind that people may get a bad idea to run it in an foreground window on a battery-powered laptop and, not suspecting anything, have their battery drained (when you are e.g. on a train, you don't notice that fans started spinning at high RPM). I suggest that you drop the fancy graphical stuff until it can be fixed in a proper way.
Created attachment 308452 [details] [review] stopwatch: Add 60FPS lock to draw_progress Gnome Clock has high CPU usage. This commit introduces a 60 frames per second lock to the rendering of stopwatch, to decrease the CPU usage.
*** Bug 738469 has been marked as a duplicate of this bug. ***
I am able to reproduce the same high CPU usage (20% in my case) whenever stopwatch or timer is used with gnome-clocks-3.18. Based on my tests the tick callbacks get delivered 60 times per second (so the patch by Lukas does not do much), and the only way I could get the CPU usage to be reasonable was to update the progress only once a second for the CountdownFrame widget. Of course, this made the progress indicator jumpy, but I got to around 2% CPU usage. Disabling the label update did not help in my case.
Anything new? We have Gnome 3.28 now and this app is still unusable on laptops.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/gnome-clocks/-/issues/ Thank you for your understanding and your help.