Syncthingtray’s CPU usage may increase linearly with Syncthing without obvious reason

[Zocker1999NET]

Relevant components

• Standalone tray application (based on Qt Widgets)
• Plasmoid/applet for Plasma desktop
• Dolphin integration
• Command line tool (syncthingctl)
• Integrated Syncthing instance (libsyncthing)
• Backend libraries

Environment and versions

• Versions of syncthingtray, qtutilities and c++utilities: 1.5.3, …, …
• Qt version: 6.7.2
• Operating system (name and version): NixOS 24.05

Bug description
(I think of it as a bug, as from the viewpoint of an user, I cannot think of a reasonable justification.)
Sometimes, the CPU usage of syncthingtray is increasing linearly with the CPU usage of Syncthing itself. I monitored this during a long synchronization (> 1 hour).
This happened while no syncthingtray window was opened, i.e. the only user-facing element of syncthingtray that was active IMO was the tray icon.
Specifically, this means that while Syncthing‘s CPU usage averaged on 40-50 %, the CPU usage of syncthingtray averaged on 10 %. When Syncthing‘s CPU usage increased to ca. 160 %, syncthingtray‘s CPU usage was on ca. 50 %. When Syncthing peaked on 200 %, syncthingtray peaked on ca. 70 %.

Steps to reproduce

1. start Syncthing & syncthingtray
2. let Syncthing sync huge amounts of data
3. check CPU usage of both processes (e.g. using htop)

Expected behavior
I do not expect that syncthingtray‘s CPU usage can increase to up to 60 or 70 % CPU just because Syncthing is synchronizing data, especially if no UI from syncthingtray is visible (aside from the tray icon). Especially when running Syncthing on a laptop, increased CPU usage has the potential to increase power usage, leading to decreased battery runtime.

Screenshots

Additional context
I wasn’t yet able to replicate the behavior consistently. Further, when Syncthing has a consistent CPU usage of ca. 20 %, syncthingtray‘s usage was below 2 % on average.
In both cases, the network utilization was consistent.

This bug occurred while syncing a directory with ca. 626,000 files in 77,000 directories using up to 94.2 GiB of space. However, some of those files are rather large. So I assume that this bug only happens when syncing a large amount of small files are synchronized.

[Martchus]

I think there's room for optimization, indeed. It would make most sense if Syncthing Tray would stop requesting disk events completely of no related UI elements are opened. Maybe I can also cut some corners when it comes to processing some of the other events when no UI elements are shown except for the tray icon. One thing I wanted to optimize as well is the handling of connection information requests which so far involves unnecessary recomputations of the status.

[Martchus]

I did a few optimizations which hopefully didn't break everything. Now the overall status is much less re-computed. The events required by the "Downloads" and "Recent changes" tabs are only requested when the corresponding tab is selected and the UI is shown at all.

This leaves still room for improvement but I'm not sure how much sense it makes.

So far Syncthing Tray is reading ItemFinished events to update the last file of each folder. This could only be done if the "Folders" tab is shown. However, then one needed to request folder statistics explicitly when that tab is opened (just like it is done initially) to get the information back in sync.

It might also be possible to avoid handling RemoteIndexUpdated or to throttle down the subsequent db/completion requests. However, I suppose it is throttled by Syncthing anyway.

[Martchus]

With 3290998 the db/completion requests on RemoteIndexUpdated events are no longer required and I also found an alternative to reading ItemFinished events. I still need to test myself how it now behaves when syncing lots of small files. You're welcome to test it yourself and provide feedback. Note that it now behaves mostly like the official UI (except that it now actually requests less events, especially when the UI is not shown).

[Zocker1999NET]

Thanks. I will immediately install the current master commit 3290998 and check if everything still works fine.

It may need a few days until I can launch another large synchronization, I will try to remember to report if and by how much your optimizations work.

[Martchus]

Thanks. I also haven't had the opportunity to test a large synchronization myself for real. However, I could come up with even more optimizations (a207c52) - even though those are more general and not related to the case of large synchronizations.