12-15% continuous CPU usage with conversation open

[gsatliawol]

• I have searched open and closed issues for duplicates

---

Bug Description

Steps to Reproduce

1. Upgrade via aptitude to 1.29.x (current X=6, I believe this was in .5 as well)
2. Open Signal Desktop as usual
3. Open Top in a terminal

Actual Result:

Top reports Signal Desktop taking a steady 15% of a CPU, and 3-4% of System, in idle state

Expected Result:

Near zero both user and system CPU

Screenshots

Platform Info

Signal Version:

1.29.6

Operating System:

ElementaryOS 5.1 Hera (Ubuntu 18.04.3 LTS) Linux 4.15.0-74 GTK 3.22.30

Linked Device Version:

Android 7.0 Signal 4.53.7

Link to Debug Log

https://debuglogs.org/8b7e615096a32a69422f391bd33b874f74f69bb452c58dacdceb6390add334e2

[scottnonnenberg-signal]

Can you talk about what is happening in the app while the CPU usage is high? Have you noticed any patterns? One thing to pay attention to is animations.

Related, if not the same issue: #2724

[gsatliawol]

It's just sitting there. I'm not running animations, disappearing messages, or anything like that. I do have a substantial message backlog and a moderate use of multimedia and emoji, but nothing that ought to need substantial CPU when the app is just sitting there out of focus and with nothing moving on the pane...

I did see 2724 and noted it was filed against 1.8; I re-looked again this morning and scrolling down noticed somebody had said 1.28 was acting similarly. I've only really noticed this in the last few weeks, though, and I've been using (and regularly updating) the Linux client for several months.

[j-dimension]

@j-dimension

[mklinik]

Same here,
Debian testing Linux 5.4.0-3-amd64 #1 SMP Debian 5.4.13-1 (2020-01-19) x86_64 GNU/Linux
signal-desktop 1.30.0
device iOS 12.4.4, signal version 3.2.1.0

When I start signal-desktop and it sits in the "Welcome to Signal" screen, it causes only very little CPU load. But as soon as I click on a contact, even one with which I have not exchanged any messages, top shows signal-desktop causing around 12% CPU load.

Attached is the output of strace -r signal-desktop of a session where I start signal-desktop, wait for some time, then click on a contact with whom I don't have any messages, and finally close signal-desktop. Maybe this gives some clue.

signal-desktop-strace.txt
https://debuglogs.org/ae089ed4ac148d0379760ad8bfd452222c6c756365addc9c7272bc327ce464e2

[scottnonnenberg-signal]

@mklinik Thanks for the additional investigation. My guess is that it has to do with timers we have running when Messages are visible in a conversation. We create a timer for each rendered message to update the relative timestamp, and, for disappearing messages, another timer to update the countdown icon. We will always need to do background updates for the UI, but perhaps limiting the number of timers total will help.

[gsatliawol]

Ooooh, that makes a LOT of sense. What if you had a single sixty-second timer and a list of messages to be updated (or a reasonably fast way to find what needs updating)? Just a thought; I haven't gone through and read source yet...

[Zepmann]

How about an option (in both Signal and Signal-desktop) to show date and time for all messages (including recent messages) instead of "x seconds/minutes/hours ago"? Problem solved.

In general I think this would make a nice feature request. Some people (among them me) prefer seeing exact times.

[gsatliawol]

I like @Zepmann's idea as an option.

[gsatliawol]

Also, I just upgraded to 1.30.0; I'm seeing one primary process spinning CPU instead of two, and the load average is much better. I'm not sure performance is optimal yet, but it is much improved.

[Zepmann]

I am running 1.30.0 as well. Idle CPU usage is 15-17%. Tested on an i7-2640M. This is far too high for an application which should just listen for incoming messages.

The high CPU usage only starts when a conversation thread is opened, giving plausibility to the idea that the relative time display is the issue.

[gsatliawol]

Agreed... however, previous behaviour was that was getting two 17% threads, so... it's progress.

[Zepmann]

For what it is worth, the issue also occurs on v1.31.0-beta.1.

[mklinik]

I'd actually prefer fixed timestamps for messages.

[amerkay]

Having the same issue on Kubuntu 18.04. Idle Signal v1.30.1 open, text only chat. I see 2 threads, one with 10-15% CPU usage and the other about 2%:

Worth mentioning, once minimized (rather just in background behind other windows), the usage drops to <1%.

Keep up the awesome work!

[gsatliawol]

@amerkay thanks for the tip! Will take to minimizing the client...

[gsatliawol]

Confirmed. With the client up in foreground on one screen, top running in the other shows three processes, the top one 20% and the bottom two about 2%. When I minimize the client to the dock, signal-desktop disappears out of Top's screen (41 lines of processes).

[kais-viz]

Noticing same issue on Kubuntu

Linux ice20 5.4.6-surface #1 SMP Fri Dec 27 22:27:31 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
,With signal v1.30.1 open

@amerkay Thanks for the simple fix for now, will keep it in mind!

[ghtdak]

I'm having the same problem on Macos. The minimization trick works great.

[pono]

I'm seeing this as well and I'm on 1.31.0 Debian 10 and Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux.
Since I'm running Gnome I have no option to minimize an application so cannot use the workaround posted in #3904 (comment)
It's also worth noting that on the 'Welcome to Signal' screen that shows just after startup, I do not see the increased CPU load.

[codido]

@pono FWIW, closing the current conversation (e.g. with ctrl-shift-c) seems to have a similar effect.

[crisidev]

I confirm closing the current conversation makes the CPU hog go away..

I am on 1.31 on Ubuntu Bionic

[pono]

@pono FWIW, closing the current conversation (e.g. with ctrl-shift-c) seems to have a similar effect.

This did it! Thanks for the help :)

[codido]

@scottnonnenberg-signal @kenpowers-signal Briefly looking at the performance data, there's an 'Animation frame fired' event at roughly 60fps when a conversation is opened, and almost never otherwise.
It seems to be coming from react-measure, which is used by a recent patch (6cc0f2a) for rendering incoming reactions.

Reverting this patch seems to help, lowering CPU utilization when a conversation is opened. Haven't really looked at what this does however, so please take this with a grain of salt :)

[codido]

If anyone else would like to give it a try, the following patches can be reverted (on top of v1.30.1) to temporarily remove the reaction rendering functionality:
f2030e9
41ca862
e5d88d7
c144412
a2aa3cb
6cc0f2a

This obviously isn't a fix, just a POC.

As a side note, the issue seems to occur regardless of the number of messages in the conversation - even conversations with no messages at all trigger it.

[jumper444]

I have a windows 10 pro machine running signal v1.31.0.
The program uses about 10% of the CPU on my machine while idle (no animations or typing or anything of that nature). Granted I have a somewhat slower mobile CPU.

If the program is minimized the CPU drops to almost nothing. (Minimize is not the same as being in the background behind another window which continues to chew CPU.)

The last 24hrs probably has 200+ messages that were sent or received and, thus, (as i read above) have a timer running which keeps updating them to show how long since they were sent (minutes, hours), until they hit 24hrs...at which point the program switches to just show the sent/received date on the message and stops timing it (let me know if my understanding is incorrect here.)

So 200+ messages (maybe even 300) are all running timers and that is what is causing my CPU usage? And minimizing the program stops the timers? Then I agree this is a problem.

For the sake of usability some of this is unnecessary
I would assert that users only need FINE grain detail of the following messages:

1. Those that I have not read yet;
2. Those that are in the visible window;
3. Those that are, say, within a few pages back of the visible window (1-3 pages);
4. Those back an hour or two or three (presuming i've already read them).

I do not find a use or value in constantly updating, down to the minute, 200-300+ messages that go pages and pages back that I have already read (or replied to) - esp when it is using 10% of my cpu.

If (as I understand it) all these timers are the problem can you cut them back to some combination of the metrics in #1-4 above (and/or whatever thoughts others have here)
?

[jumper444]

Since this thread is about high CPU usage (on linux, but I'm having same issue on windows) may I say:

1. I've had animated images sent to me that chewed up CPU also. I have not tested what happens when they scroll off the screen but I would hope (and ask) that animations stop once they become invisible. (In my case the animation was so bad I simply deleted the message immediately so I don't know what happens when it scrolls up.) For firefox I also have the option to only show an animated image for one loop, then it stops. That might already be a default feature or display option with Chrome which is what I think you are using underlying. An idea.

2. The TYPING animation/indicator is very excessive on CPU usage also. That is unnecessary and just putting in cute flash over usability, imo. Can you consider just displaying something like a little yellow box with the word [TYPING] in it or something like that and bypass animating three dots? My computer takes a noticable speed lag/hit simply when a person starts typing a message to me and I have other uses for what my computer is doing.

Thanks for the consideration. If these belong in a separate issue I'm sorry and will move them there.

[codido]

@jumper444 Do you see lower CPU usage when the current conversation is closed (e.g. with ctrl-shift-c)? What about when the active conversation is an empty one?

If both of these lower the CPU utilization, this is likely related to the reactions code mentioned in #3904 (comment), and probably not a timers issue (since there are no displayed messages at all).
This issue seems to reproduce in Linux and Mac, so I would guess the Windows client would also experience this.

That being said, the above is only relevant for idle cases (that is, no animations, etc).

[jumper444]

More information to answer and assist:

1. when I start the program (after it becomes steady state) and when my message window is blank (aka says "Welcome to Signal Select a contact or group...") (and the contacts and groups are on the left)...the CPU usage is minimal. (Although the left contact list does show the single most recent message from each group/contact under it and that message does have a timer).

2. If i then select a contact with NO messages (one I haven't used in weeks; the message screen just has a few "you've marked this as verified" type service messages), then the cpu surprisingly ramps up to the 10% or so. (I did not test or expect this since I'm not currently displaying a group or contact with large messages.) Hmmm.

3. If i then click on (display) a group/contact with hundreds of messages the cpu usage remains at the previously mentioned 10% (no animations, no typing, nothing weird going on, etc.) So actually this cpu usage problem from my view is not dependent on the current thread of displayed messages, but (see below) the actual displaying of ANY contact or group in the main window.

4. If i then do a ctrl-shift-c (which clears the message window which goes back to "welcome to signal...choose a contact or group") the CPU goes down to minimal as similar to when I started it up in # 1 (after steady state).

5. All my contacts and messages are using 'disappear after 1 week' if this is useful info.

6. If I minimize signal during situation # 2 or # 3 above, the CPU usage will (shortly) return to minimal (not exactly zero, but what I perceive is probably 'normal' and appropriate.)

[jumper444]

FYI: i have a celeron N3350 which has a speed rating of 1112 on this common benchmark:
https://www.cpubenchmark.net/cpu_list.php

This is more than adequate and also typical for more mobile or long-battery devices, however many of you guys are probably using machines in the 3000+ benchmark range (you can do a quick search to view yours if you want).

I mention this because often devs don't experience the lag and slowdown of more 'regular' users due to the hardware diff. 10% cpu (or higher during 'typing' and such on my machine is quite noticable) whereas on more power cpu's you won't be able to pick this up.

[jumper444]

I guess it goes without saying but I should add that I don't recall this 10% cpu usage hit (while no typing or animations or such) existing more than maybe a few days (a week or so??).

I can't say when it started but it certainly hasn't been there for months and I noticed it soon enough to start searching github here. This issue was opened a month ago so maybe it's been that long. it's possible.

[codido]

@jumper444 From what you're describing, this seems to be exactly the same issue as mentioned in #3904 (comment). It was introduced just before v1.30, so if you've been using v1.29.6 or lower that explains it.

I believe the original issue submitted here and the one we're seeing now might be two different issues. The original issue might have been fixed already or simply not easily reproduced unlike the reactions one.

[jumper444]

There have been two version updates on my machine (I believe). I'm now using v1.31.1 (Win10;64bit).

There is no change in the high CPU usage when otherwise it should be minimal. (In fact it seems to be slightly worse):

CPU usage with a thread open: 15% (no animated gifs or emojies or such running).
CPU usage drops to 0.4% when I hit ctrl-shift-c and return the right side window to "Welcome to Signal" without displaying a thread.

[jumper444]

SUGGESTION: change title of this issue to remove "linux" since this problem appears to exist on all platforms:

"high CPU usage on desktop client [when threads are open]"
?

[nh2]

I guess it goes without saying but I should add that I don't recall this 10% cpu usage hit (while no typing or animations or such) existing more than maybe a few days (a week or so??).

Coming over from the just-closed (older) duplicate #2724:

That issue has been reporting high CPU useage from at least 6 Sep 2018.

[vchryssos]

Still there in v.1.32.1 (Ubuntu 18.04 LTS) with top displaying one or two Signal-desktop threads with 11 - 13,6% of CPU when idle.

[Lion-box]

Confirm same behaviour on Ubuntu 19.10 with latest 1.32.1
One signal related process uses 13% cpu on average whenever a conversation is open, even if it is a new clean and empty conv.
Minimizing signal window or closing the conversation temporary fixes the issue.

the process using around 13% cpu has the following command line:

/opt/Signal/signal-desktop --type=renderer --no-sandbox --field-trial-handle=13175329725273314245,2904109776812704433,131072 --enable-features=WebComponentsV0Enabled --disable-features=SpareRendererForSitePerProcess --lang=it --app-path=/opt/Signal/resources/app.asar --no-sandbox --no-zygote --native-window-open --preload=/opt/Signal/resources/app.asar/preload.js --enable-remote-module --background-color=#2090EA --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=5 --no-v8-untrusted-code-mitigations --shared-files=v8_snapshot_data:100

[vchryssos]

Minimizing signal window or closing the conversation temporary fixes the issue.

Yeap, same here. Thank you @Lion-box for this.

[codido]

@kenpowers-signal Just making sure this didn't get lost in the thread - have you had the chance to look into #3904 (comment) and #3904 (comment), since that looks like the culprit for this particular issue (but not to earlier high CPU utilization reports)?

[kenpowers-signal]

@codido It's something I'll be looking into soon.

[codido]

@kenpowers-signal I can confirm that your 17f212f patch seems to have fixed this issue, and as a result 1.33.0-beta.3 no longer experiences it.

Thanks!

[ProactiveServices]

Signal 1.32.3 on Ubuntu 19.10, still seeing the same problem. 10-20% CPU usage until I close a conversation, then it immediately idles. The conversation has a few audios and one static screenshot displayed in the past 24 hours. Some URLs but I have previews disabled.

Performance profile:
Profile-20200330T041028.zip
Debug log from ~10 minutes before profiling to just after:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Signal/1.32.3 Chrome/80.0.3987.134 Electron/8.0.3 Safari/537.36 node/12.13.0 env/production
<snip>
INFO  2020-03-30T03:00:27.442Z Sending a keepalive message
INFO  2020-03-30T03:01:22.533Z Sending a keepalive message
INFO  2020-03-30T03:02:17.624Z Sending a keepalive message
INFO  2020-03-30T03:03:12.716Z Sending a keepalive message
INFO  2020-03-30T03:04:07.807Z Sending a keepalive message
INFO  2020-03-30T03:05:02.900Z Sending a keepalive message
INFO  2020-03-30T03:05:41.684Z Remove all notifications
INFO  2020-03-30T03:05:46.693Z Remove all notifications
INFO  2020-03-30T03:05:47.713Z SQL channel job 17968 (updateConversations) succeeded in 13ms
INFO  2020-03-30T03:05:58.020Z Sending a keepalive message
INFO  2020-03-30T03:06:07.445Z Remove all notifications
INFO  2020-03-30T03:06:53.111Z Sending a keepalive message
INFO  2020-03-30T03:07:48.201Z Sending a keepalive message
INFO  2020-03-30T03:07:48.939Z Remove all notifications
INFO  2020-03-30T03:07:53.940Z Remove all notifications
INFO  2020-03-30T03:08:04.130Z Remove all notifications
INFO  2020-03-30T03:08:05.450Z SQL channel job 17982 (updateConversations) succeeded in 12ms
INFO  2020-03-30T03:08:43.301Z Sending a keepalive message
INFO  2020-03-30T03:09:38.393Z Sending a keepalive message
INFO  2020-03-30T03:10:33.482Z Sending a keepalive message
INFO  2020-03-30T03:11:33.986Z Remove all notifications

[Lion-box]

That's totally expected as the fix only landed 6 days ago in v1.33.0-beta3.
Will be available to non beta users as soon as v1.33 reaches production.

[ProactiveServices]

That's totally expected as the fix only landed 6 days ago in v1.33.0-beta3.
Will be available to non beta users as soon as v1.33 reaches production.

Oh, of course! My apologies. I think I was confused by the multitude of twos and threes at play :-)

[gsatliawol]

Can confirm 1.33.0 sees expected behaviour ... yay! Thanks, everybody!

[arkenoi]

Still see the problem with 1.33.0. However, my CPU is core2duo but it does not mean it is just "too old" I hope.

[jumper444]

The thread was closed already so I didn't comment but now with it open again I want to confirm that this bug was fixed from my point of view. CPU usage almost 0% (v1.33.0; windows 10(64bit of course)). NOTE to ARKENOI, my CPU is probably slower than yours even (and that is normal for small/portable devices nowdays. Nothing wrong with it. If you look above you can see in a post the benchmark of the CPU I was reporting and its speed as well as how to look up what you use to get a relative idea of where yours fits in if it matters.)

[alex005005]

I am still experiencing high CPU load.

Edit: Deleted all the data and now it seems to be fixed.

[jumper444]

If you had animated images, gifs, or emojis that had been sent (to or from) in a thread then I suspect the program continues to animate as long as they exist (whether shown on screen or not). I have received such from people before and delete them immediately after viewing instead of allowing to stay/accumulate on a thread - they would load up CPU uselessly. Just an fyi you might not have considered...and you said it went away after deleting messages.

You could have had some small animated joke-cat cartoon or something from days or weeks ago way back in a message thread.

[gsatliawol]

Interesting. Just upgraded to 1.33.1 and Signal has completely disappeared from my 53-line top display. ps(1) shows the processes are there... a master process, a zygote, a gpu process, a utility process, and the renderer... but in four hours and eight minutes wall clock the master had racked up 27 seconds of CPU time and the renderer 26, and the rest were single-digits. (By comparison, 1.33.0 was still taking small but visible percentages of CPU - and Discord and Slack are still visible on top's display, along with top itself...)

[stubu]

1.34.1 chomping CPU in Fedora 31. I think 1.33 was relatively good but now the bug is back. Consuming a whole core and I'm doing nothing.

[RalfJung]

I am also still experiencing permanent CPI load except when Signal is minimized. Opened a new issue: #4459.