After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710332 - High CPU load when timer or stopwatch is running
High CPU load when timer or stopwatch is running
Product: gnome-clocks
Classification: Applications
Component: general
Other Linux
: Normal normal
: ---
Assigned To: Clocks maintainer(s)
Clocks maintainer(s)
: 738469 (view as bug list)
Depends on:
Reported: 2013-10-16 22:30 UTC by Soulou
Modified: 2021-06-01 22:44 UTC
See Also:
GNOME target: ---
GNOME version: ---

screenshot of the high cpu load when using clocks (406.26 KB, image/png)
2013-11-05 17:24 UTC, fred
Two full strace logs (line by line) (7.79 KB, text/plain)
2014-02-16 17:06 UTC, Miroslav Puda
perf (1.88 KB, text/plain)
2014-02-19 21:44 UTC, Miroslav Puda
perf (791 bytes, text/x-log)
2014-02-19 22:30 UTC, Miroslav Puda
stopwatch: Add 60FPS lock to draw_progress (1.53 KB, patch)
2015-07-30 13:09 UTC, Lukas Venhoda
none Details | Review

Description Soulou 2013-10-16 22:30:28 UTC
I'm running last GNOME (3.10.1) with Archlinux 64bits

Here is my issue:

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!
Comment 1 fred 2013-11-05 17:24:34 UTC
Created attachment 259030 [details]
screenshot of the high cpu load when using clocks

I also notice the same problem with the high cpu load.
Comment 2 Paolo Borelli 2013-11-05 18:35:31 UTC
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.
Comment 3 Evgeny Bobkin 2013-11-06 09:40:23 UTC
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?
Comment 4 Evgeny Bobkin 2013-11-06 10:34:23 UTC
or maybe it's due to the add_tick_callback, which is too frequently
Comment 5 Jean-François Fortin Tam 2014-02-02 18:53:58 UTC
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).
Comment 6 Miroslav Puda 2014-02-12 16:00:37 UTC

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.
Comment 7 Paolo Borelli 2014-02-12 16:56:37 UTC
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
Comment 8 Miroslav Puda 2014-02-16 17:05:04 UTC
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
Comment 9 Miroslav Puda 2014-02-16 17:06:57 UTC
Created attachment 269315 [details]
Two full strace logs (line by line)
Comment 10 Miroslav Puda 2014-02-16 18:24:06 UTC
CPU load goes down if you switch to different tab (from Stopwatch/Timer to another).
Comment 11 Miroslav Puda 2014-02-19 21:44:06 UTC
Created attachment 269733 [details]
Comment 12 Miroslav Puda 2014-02-19 21:46:27 UTC
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 13 Miroslav Puda 2014-02-19 21:48:09 UTC
Comment on attachment 269733 [details]

perf.hist.1 and perf.hist.2 shows zoom on first two items in perf.hist.0
Comment 14 Miroslav Puda 2014-02-19 22:30:11 UTC
Created attachment 269735 [details]
Comment 15 Miroslav Puda 2014-03-26 17:32:16 UTC
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.
Comment 16 Gustavo Noronha (kov) 2014-04-04 14:15:02 UTC
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?
Comment 17 Matthias Clasen 2014-04-05 00:50:41 UTC
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.
Comment 18 Matthias Clasen 2014-04-05 02:50:51 UTC
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.
Comment 19 Matthias Clasen 2014-04-05 03:27:59 UTC
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.
Comment 20 Matěj Týč 2015-06-03 21:28:17 UTC
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.
Comment 21 Lukas Venhoda 2015-07-30 13:09:57 UTC
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.
Comment 22 Alexandre Franke 2015-11-04 15:18:01 UTC
*** Bug 738469 has been marked as a duplicate of this bug. ***
Comment 23 Roman Yepishev 2016-01-04 03:16:42 UTC
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.
Comment 24 gnome 2018-04-05 18:18:23 UTC
Anything new? We have Gnome 3.28 now and this app is still unusable on laptops.
Comment 25 André Klapper 2021-06-01 22:44:15 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
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
and create a new enhancement request ticket at

Thank you for your understanding and your help.