Permanent CPU load when nothing is happening

[RalfJung]

• [x] I have searched open and closed issues for duplicates

---

Bug Description

After opening Signal-Desktop, even when nothing is happening in the open conversation (no animation or disappearing message or anything like that), there is a 50% load (meaning 50% of one CPU core) permanently. Only minimizing the window makes that load disappear.

This issue was reported before (https://github.com/signalapp/Signal-Desktop/issues/3904), but that one was closed with a fix claimed for v1.33. However, that fix does not seem to help here (and others are reporting the same in that issue).

Steps to Reproduce

1. Open Signal
2. Select a Conversation
3. Alt-tab to a process manager

Actual Result:

The process manager (htop in my case) show 50% CPU load (this is relative to 1 core).

Expected Result:

There should not be noticeable load when nothing is happening.

Platform Info

Signal Version:

Operating System: 1.34.5

Linked Device Version: 4.64.5

Link to Debug Log

https://debuglogs.org/436ed8e435336c02cf3c19ab6bd5b7fdbd3bfb3f5738de984fe5ca568b79480b

[scottnonnenberg-signal]

The scenario you mention - how many messages from the server were processed? And then, what happens to CPU usage after a couple minutes?

I would expect relatively high CPU usage after startup, as things are being loaded and run for the first time, but then things would settle down.

[RalfJung]

I started measuring only after things settled down. So there are no messages received at all, as far as I can see.

Even now, 12h later (I had Signal minimized all the time), when I un-minimize it, I get 50% load.

[scottnonnenberg-signal]

@RalfJung Can you talk a little more about your hardware, the details of how CPU usage changes?

Do you use disappearing messages heavily? Are a lot of messages showing when CPU usage is high? Or does it even happen in an empty conversation?

Then, what kind of CPU usage do you see in Chromium? Does it also use a lot of CPU to render a web page?

[RalfJung]

Can you talk a little more about your hardware, the details of how CPU usage changes?

Not sure what to say here... cpuinfo says "Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz", I have 4 physical cores and hyperthreading (so 8 logical cores).

CPU usage of the signal process changes from basically nothing to 40-50% when I un-minimize Signal.

Do you use disappearing messages heavily? Are a lot of messages showing when CPU usage is high? Or does it even happen in an empty conversation?

I don't use disappearing messages at all. The number of messages that show are what fits on my screen (1920x1200px)... around 10 I'd say.

I tried various different conversations, and that seems to have no effect. But what I just noticed is that when I scroll down in the conversations list on the left (but leave the active conversation on the right the same), the load goes away. So it seems to have something to do with that list.

Then, what kind of CPU usage do you see in Chromium? Does it also use a lot of CPU to render a web page?

I don't use Chromium. But I use vscode, another electron app, and while it sometimes has background load, it is not nearly as high as Signal's. Also the fact that scrolling down makes the load go away IMO demonstrates that this is a Signal issue.

[scottnonnenberg-signal]

The more you can narrow down exactly what UI elements are causing this, the more it would help us. I see that you're not using the beta - you could set up a second instance on that same machine via the beta, and do some experiments. It would really help. Thanks!

[jeffdgr8]

I've been seeing this as well. After the Signal app has been open for a while, my computer will often become bogged down with low CPU resources and checking the process manager Signal is taking 100% CPU. I'm running 1.34.5 in Linux on Chrome OS. I have a Core i7 Y-series CPU, plenty powerful for bursts of short loads, but really can't handle sustained heavy CPU loads well.

I don't use disappearing messages at all either. My 12" screen can show 5-10 messages in a conversation at once. Seems like most of the time I've seen this happen was after I'd had the app open and received a bunch of messages, mostly in one single conversation, during the day.

[RalfJung]

I see it happen even when I restart Signal -- i.e., when there are no new messages and Signal runs in a fresh instance.

[ProactiveServices]

I intermittently see the same behaviour here - 12-15% CPU - with a one-to-one conversation open, with a conversation that has no history, a relatively quiet group of three people, with note to self and with the chat window closed via Ctrl-C. None of the conversations have any recent reactions, animated media or stickers.

Kubuntu 20.04 LTS using Signal 1.36.1-beta.2, 2.6GHz Intel Core i5.

[scottnonnenberg-signal]

@ProactiveServices if we could get a look at your log, that would help us determine if Signal is doing any work in the background during that time.

[ProactiveServices]

https://debuglogs.org/960de9f4e655458c69482aff31a32be4f7b8b55cef6e89663716bfab1c76bf0f

[ProactiveServices]

I've also captured a 60s performance profile from the devtools, if that'll be helpful - if so do I need to anonymise any of the data present in it?

[scottnonnenberg-signal]

@ProactiveServices My understanding is that the only identifiable information in those kinds of performance traces are the screenshots. They can be really useful to help track things down, of course. But then again we're not interested in relating your log to user action, but inaction. I don't think we need them. Please feel free to send your log to one of us directly, or to support. Thanks!

[kentchristopher]

I'm getting a constant 5% CPU usage in v1.37.2 on Kubuntu which I found is due to a link preview in one recent message. Clicking on another contact with no messages made it go away but that's temporary. Deleting the message with the link stopped it.

There should really be an option to turn off previews.

[scottnonnenberg-signal]

@kentchristopher Is there anything else you can tell us about the link preview contents? Was there perhaps an animated gif included? Was it a disappearing message? Anything else out of the ordinary?

[kentchristopher]

@scottnonnenberg-signal, no animated gif, not a disappearing message - just a URL, this one in case you want to try to replicate.

[rebastion]

One reason I had erroneously switched to the snap version (I just switched back knowing it's not officially supported) was the high CPU use. So now I am back on the official Signal, and lo and behold. Not doing anything it is at 17% CPU, fans blowing for no reason. And that is several minutes after launch of the app - and there is nothing to process because it doesn't carry over old conversations ("For your security, conversation history isn't transferred to new linked devices.")..... it even keeps on doing that after I quit signal

[ProactiveServices]

Debug log from Signal 1.39.4-beta 1, Kubuntu 20.04.1. The only activity, since it was idle, has been a small number of messages in a V2 group of three members. The problem is recurring multiple times a day, only way to solve it seems to be to frequently close and re-open.

[kaimast]

I'm getting a constant 5% CPU usage in v1.37.2 on Kubuntu which I found is due to a link preview in one recent message. Clicking on another contact with no messages made it go away but that's temporary. Deleting the message with the link stopped it.

There should really be an option to turn off previews.

I seem to always have 5% CPU usage. Even when the application is minimized. Maybe this is related to #4883?

Somewhat unrelated: I also have about 600mb of memory usage, which seems extremely high considering I only have about 5 people I talk to on this app. Probably less than 500 messages in total.

[ProactiveServices]

@kaimast a debug log may be of assistance for diagnosis.

[ProactiveServices]

Debug log for the issue in 1.40.0-beta4

[kaimast]

Lets maybe just wait until Signal has been ported to Electron 11 (or 12). My hope is that some of the performance issues will be resolved then.

[kaimast]

Here's my log on 1.40 https://debuglogs.org/f6158dd159e830e0598e444c15ad6506df5364771c5e8c340f7f4f1631265f8b

It seems to be even worse now? About 10-12% CPU usage.

[diegoe]

FWIW I can only reproduce this when animated stickers are on screen. It's pretty clear when you display a sticker sheet and everything starts to slow down in Signal. Happens in Linux/macOS.

Using the web dev tools profiler clearly shows that the CPU keeps waking up to loop the animated GIF. If I hide or destroy the HTML element, the CPU goes idle, almost to 0%. Same happens if I switch to a plain text conversation, 20-30% CPU whenever GIFs are in screen. As others have suggested in other reports similar to this one, minimizing Signal drops the CPU use too.

I'd argue this is clearly a limitation of whatever the shipped Electron is doing. Maybe it's failing to detect GPU acceleration? Maybe it's built with less than ideal build options? I don't know, but I can confirm positively that GIFs trigger this issue. Similarly, on mobile, stickers algo make Signal crawl, specially if you have many packs installed.

My hot take is that GIFs shouldn't loop forever, but stop after X loops (which I have no clue how to measure on pure HTML/JS, but I guess there are npm modules for that?).

There are some hacky approaches like using canvas to create a "freeze frame": https://github.com/krasimir/gifffer/blob/master/lib/gifffer.js

I'd maybe articulate a possible solution as: "Make animated stickers loop only X times, and only play when visible" -- Would something along these lines be considered an acceptable change @scottnonnenberg-signal?

See similar: https://github.com/signalapp/Signal-Desktop/issues/3997

[ProactiveServices]

I almost never receive animated stickers or pictures and end up with 20-40% CPU usage after about 15 minutes of use, often with only a handful of text messages received.

[scottnonnenberg-signal]

@diegoe Yeah, I think that'd be a fine PR. Do note that with our scroll virtualization, scrolling up and down, or even resizing the window horizontally, would likely reset the timer.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tomtastic]

bump

[fdutheil]

Hi, I remember having the same issue as long I started using Signal on Linux years ago. Restarting Signal-Desktop for it to only show the startup screen temporarily to the trick.

My suggestion: Is there a way to add and expose a configuration knob in Signal-Desktop's settings to "disable GPU hardware acceleration" if it is enabled by default (*)? Because I can see this too on a famous corporate and (censored) messaging application using Electron on Linux too, and disabling GPU benefited tremendously there (like CPU usage divided by 10 on Intel iGPU hardware).

(*) I use Signal-desktop on windows too, and I highly suspects it has GPU hardware acceleration enabled by default, because my windows AMD driver is likely to crash whenever I have a GPU hardware accelerated application on my second screen while gaming on the main screen (brraaaah, yeah, known issue for years, never fixed). Having disabled "GPU hardware acceleration" in all apps I use (Firefox, and all Electron based apps except Signal), I can confirm the display driver now only crashes when Signal is started.

[RichardMyersGV]

On Linux... Signal 5.24.0. Signal constantly uses 8-9% (of 8 cores)....doing nothing but using resources.

I love the app, but please folks, design efficient SW! It should not consume anything if I'm not interacting with it. And in general, I should never see any usage on an 8-core machine. Really! It's a messaging app... it doesn't have to DO anything (which consumes enough resources to register). If it was mining Bitcoins, or doing circuit simulations, or hosting many busy websites, then sure use some CPU time. But Signal is just a messaging app. It has to keep up with me typing every so often, and maybe a response from someone else.

If it's a GPU hardware acceleration thing, then please add an option in preferences to enable it or disable using the GPU.

[hiqua]

@RichardMyersGV debug log?

[RichardMyersGV]

I can't seem to attach it for some reason... ("is not included in the list" shows in red...). Here's a link. https://debuglogs.org/a2605494af25fc759faeefdee204d66edeea8065c278258bc6de9420a23e114c.gz -Richard

[ProactiveServices]

I've been suffering this for years. Current debug log

[RichardMyersGV]

Minimizing helps, but it still uses 1-2%, which I think is way too much. And I'd rather not have to minimize it, as I miss things....

[kaimast]

As mentioned in #1648 I cannot reproduce this anymore on Wayland/GNOME. When in the background, Signal stays at 2% for a few seconds and then goes to virtually 0% CPU usage.

[RichardMyersGV]

Wondering if this has anything to do with my issue... I have a little spinning icon on the left pane of the screen next to one contact (conversation). I believe the contact left Signal, and my last message never made it to him, so the icon just spins forever. This icon is in the same place as the little checkmarks to the right of the contact name on the left-hand pane. Anyway, could it be related?

Also, the process has --type=gpu-process has about 5% usage, and the process which has --type=renderer has about 4% usage with nothing going on. The other --types have 0%.

@Kaimast, thank you! But I couldn't find anything actionable in #1648 other than moving to Wayland. Seems like X shouldn't be the issue... I have the latest version, 5.24.0, which is another supposed 'fix'.

I'm running Fedora 33 (signal-desktop-5.24.0-1.fc33.x86_64). I'll likely get forced to Wayland when I upgrade Fedora soon...

[g6094199]

is see the same problem on

ubuntu 21.10

with the xenial .deb package (signal 5.24.0, 5.23.x) from your repo,

but NOT with the SNAP package (signal 5.23.1) from the ubuntu snapstore,

[kaimast]

Wondering if this has anything to do with my issue... I have a little spinning icon on the left pane of the screen next to one contact (conversation). I believe the contact left Signal, and my last message never made it to him, so the icon just spins forever. This icon is in the same place as the little checkmarks to the right of the contact name on the left-hand pane. Anyway, could it be related?

I assume if there's some animated symbol that could cause frequent redraws.

@kaimast, thank you! But I couldn't find anything actionable in #1648 other than moving to Wayland. Seems like X shouldn't be the issue... I have the latest version, 5.24.0, which is another supposed 'fix'.

I know there has been some work in Wayland to not request redraws for windows that are occluded.

[luminoso]

I was wondering that this was just me. haha

I saw a few posts saying that disabling gpu hardware acceleration solves the issue but never managed to disable it.

This is so bad that when I want an extra hour in laptop battery life I just close Signal 😂

[RichardMyersGV]

Wondering if this has anything to do with my issue... I have a little spinning icon on the left pane of the screen next to one contact (conversation). I believe the contact left Signal, and my last message never made it to him, so the icon just spins forever. This icon is in the same place as the little checkmarks to the right of the contact name on the left-hand pane. Anyway, could it be related?

I assume if there's some animated symbol that could cause frequent redraws.

Do you know how I could report this issue to the developers? If this spinning icon is causing redraws, then this is a bug (it should time out, or whatever, not cause lots of cpu usage forever).

[RichardMyersGV]

Verified that deleting the last undelivered message (for me) helped. It got rid of the spinning icon, and now the CPU usage is the same whether minimized or not. Signal is down to about 1.5% of an 8-core machine, which is still too much for doing nothing, but is much better. I hope the devs can see this post and fix the issue. An undelivered message should not consume CPU forever. That's a LOT of power wasted the world over...

[bauereiss]

I believe I had the same issue as @RichardMyersGV . An outgoing message was stuck because the contact had left Signal in the meantime, and there was a spinning icon next to the contact. Signal had been continuously causing high CPU load for me (around 40% when I last looked) for the past few weeks when running (and not minimized). After deleting that message, CPU usage instantly dropped and is now close to zero when idling.

[fdutheil]

I've ruled out the "GPU rendered vs CPU rendered" to be unrelated to this (thanks to the --disable-gpu --force-cpu-draw options). In my use case: freshly started Signal is always OK, then after 12 or 24 hours (with a couple of suspend to RAM/resume cycles of the laptop), things starts to get bad: I can see up to 10-20% CPU usage. Restarting Signal and getting into the exact same discussion it was when high CPU load while idling always gets the situation under control again (having an animated stickers visible or not seems not relevant either).

[chronos000]

I am seeing the same behavior on two different computers using Pop!_OS 21.04. Signal version 5.26.1. Installed via flatpak (app id org.signal.Signal).

If I restart Signal, CPU usage returns to normal (almost 0%). But I did notice that idle CPU usage strarts raising as soon as I received the first messages during the current run. This is even worse after receiving calls.

I suspected that it might have something to do with notifications, so I tried disabling notifications (in signal's preferences). This seems to solve this problem, and idle CPU utilization returns to almost cero.

I played arround quite a bit with the rest of the notification options in Signal, and narrowed down the the trigger (at least in my case), to just be the notification sounds. If I enable all notification options except for "notification sounds", idle CPU utilization remains low even after receiving several messages and having notification popups.

However, after receiving a call the idle CPU utilization starts climbing again. Interestingly, I can't avoid this problem by disabling "show notifications for calls". Even if I disable this option, the desktop notifitacion popup is still shown, the ring is still played, and the idle CPU utilization starts rising.

If I instead MAKE a call to someone (thus not producing a desktop notification), then idle CPU utilization remains low.

I can provide a debug run, or log, if someone can point me in the right direction on how to do it.

[lnicola]

Interesting, does it keep the audio session open after a notification sound? You can check by opening pavucontrol, I guess.

[chronos000]

does it keep the audio session open after a notification sound?

@lnicola when notification sounds are on, and a message is received, I see a new "chromium" audio session spawned, but it's closed 10~15 seconds after the notification. Seems to be appropriate handling of the audio session

[xadhatter]

Hey @chronos000, thanks for the research and linking here from the other ticket. Unfortunately, your work around of disabling notification did not resolve the issue for me. Signal continues to use ~10% CPU while hidden and idle.

[chronos000]

@xadhatter did you restart signal after changing the notification settings?

[xadhatter]

@chronos000 I did. Also tried several different combos (only unchecked sound, unchecked everything, etc).

[brzd]

EDIT: Also discussed here #5637

Similar issues with sometimes over 30% CPU usage, while on the background. I rarely shutdown or restart my computers, so this is quite annoying feature. Only workaround (a bad one) is to close signal and terminate related processes (if left behind) and start it again.

Has anyone tried tracing gif and other media that may cause load issues if ran in the background for long period of time in several message streams?

[FiSHYsolutions]

issue confirmed. using xubuntu 20.04.3 LTS: signal-desktop (apt) v5.28.0 causes constant 20% cpu load and consumes a ridiculous amount of RAM. signal-desktop (snap) v5.26.0 still consumes a ridiculous amount of RAM but doesn't cause high cpu load.