Wire Web/Desktop constantly uses CPU during idle

[rawlife56]

Wire version: 3.9.2895
Wire for web version: 2019.04.10.0901
Operating system: Linux (Arch-KDE)

What steps will reproduce the problem?

1. Open Wire
2. Close and let it sit in the tray
3. Check the constant CPU usage of 2-4% with some spikes upto 10% in regular intervals without any incoming messages.

What is the expected result?
No CPU usage and minimal CPU usage in intervals if needed.

What is the actual result?
Constant CPU usage of 2-4% with some spikes upto 10% in regular interval

Workarounds I tried-
Searched across issues and found few like these which are quite old & irrelevant.

Strange findings-

1. It also happens in the web app. Tried in Firefox browser and Rambox with the clean chats, both resulted in the same constant CPU usage.
2. Few specific conversations result in constant 10% CPU usage. (including idle.)

A note about screenshots - Every Electron instance running in this pic is from Wire. This doesn't happen with other electron applications. I took extreme care before capturing these screenshots verifying it's only the Wire running and also did check whether killing wire would terminate these processes too. Yes, they did terminate if I kill wire.

'

[fermulator]

This is a regression I think, I am observing new significant degrade in battery life on notebook for similar reasons. (debug of CPU busy blames wire-desktop) - this DID NOT used to be a problem (at least for the recent past)

 ps wauxxx | grep wire-desktop | sort -rnk3 | head -1
fermula+  9107  8.4  3.7 12519836 296416 ?     Sl   12:20   1:05 /tmp/.mount_wire-3UoYI5y/wire-desktop --type=renderer --no-sandbox --enable-features=SharedArrayBuffer --disable-gpu-compositing --service-pipe-token=17888110652218941075 --lang=en-GB --app-path=/tmp/.mount_wire-3UoYI5y/resources/app --node-integration=false --webview-tag=true --no-sandbox --preload=/tmp/.mount_wire-3UoYI5y/resources/app/renderer/static/webview-preload.js --background-color=#fff --guest-instance-id=1 --enable-blink-features --disable-blink-features --num-raster-threads=2 --enable-main-frame-before-activation --service-request-channel-token=17888110652218941075 --renderer-client-id=6 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101

Here's the startup sequence: (it takes a VERY long time to "settle CPU")

$ while true; do ps wauxxx | grep wire-desktop | sort -rnk3 | head -1 | awk '{print $3}'; sleep 1; done
0.0
0.0
0.0
19.0   <-- open wire-desktop
40.5
47.0
31.0
30.0
58.0
55.0
50.6
50.7
48.2
55.5
63.5
64.2
60.3
57.2
53.5
50.3
47.5
45.1
42.9
41.0
39.2
37.6
36.1
34.7
33.5
32.4
31.3
29.2
28.4
27.7
26.9
26.2
25.6
25.0
24.4
23.8
23.3
22.8
22.4
22.0
21.6
21.2
20.9
20.5
20.2
19.9
19.6
19.3
19.0
18.7
18.4
^[18.9
19.3
19.0
18.8
18.5
18.3
18.1
17.8
17.3
17.2
17.0
16.9
16.7
16.5
16.3
16.2
16.0
15.9
15.7
15.5
15.4
15.3
15.1
15.0
14.9
14.8
14.6
14.5
14.4
14.3
14.2
14.1
14.0
13.9
13.8
13.7
(got tired of waiting)

Here's an "idle" scenario (after its been open for hours or whatever)

$ top -H | grep 11233
11233 fermula+  20   0 11.898g 230568  90280 S  3.0  2.9   0:18.80 wire-desktop                                                                                         
11233 fermula+  20   0 11.898g 230568  90280 S  2.6  2.9   0:18.88 wire-desktop                                                                                         
11233 fermula+  20   0 11.898g 230588  90280 S  3.0  2.9   0:18.97 wire-desktop                                                                                         
11233 fermula+  20   0 11.898g 230568  90280 S  3.0  2.9   0:19.06 wire-desktop                                                                                         
11233 fermula+  20   0 11.898g 230568  90280 S  2.6  2.9   0:19.14 wire-desktop   

$ while true; do ps wauxxx | grep wire-desktop | sort -rnk3 | head -1 | awk '{print $3}'; sleep 1; done
8.2
8.2
8.2
8.2
8.2
8.2
8.2
8.2
8.4
8.5
8.5
8.5
8.5
8.5
8.6
8.8
8.8
8.8
8.8
8.8
8.8
8.8
8.8
8.8
8.8
8.8
8.8
8.8
8.8
0.0    <--- exit wire
0.0
0.0

Sys Info:

Linux Mint 18.3 Sylvia
4.15.0-43-generic
mate-desktop 1.18.0-1+sonya

Wire is wire desktop: 3.5.2881 2019.04.10.0901 (run out of appimage)
launches like this I think

~/.local/share/applications$ cat appimagekit-wire-desktop.desktop 
[Desktop Entry]
Name=Wire
Comment=The most secure collaboration platform.
Exec="/home/fermulator/bin/wire-3.5.2881-x86_64.AppImage" %U
Terminal=false
Type=Application
Icon=appimagekit-wire-desktop
StartupWMClass=Wire
X-AppImage-Version=3.5.2881.2881
Categories=Network;
X-AppImage-BuildId=1EfGcRPwIYawPq5bKmAnl2JIE4o
X-Desktop-File-Install-Version=0.22
X-AppImage-Comment=Generated by /tmp/.mount_wire-3fzJ6fG/AppRun
TryExec=/home/fermulator/bin/wire-3.5.2881-x86_64.AppImage

[fermulator]

I also report similar CPU vs. chat behaviour. It doesn't seem to matter which conversation the app sits idle in.

[fermulator]

Any recent changes to suspect? I scanned briefly but not sure exactly when the regression was introduced so not sure how far back to go.

[wilhelmy]

Same here, it constantly eats 9% CPU. I've quit it for now, this is unreasonable.

[Mikaela]

I think I am also seeing this on Debian Testing with Wire 3.9.2895 (from Flatpak). I also find that --no-sandbox strange, why is it there?

I hope that the root on the bottom is due to using Flatpak and it's related to Flatpak's own sandboxing instead of Wire actually running as root.

[tomleb]

I am having the same issue.
Getting 15% cpu usage when idle and 75% cpu usage when focusing the application.

[fermulator]

I checked on my Win10 system and the same idle CPU is happening there too :/
(so not a linux/container specific problem? can anyone else corroborate this?)

[fermulator]

fwiw, I contacted support directly and they refuse to help; only "professional" tier users get support, and they don't support linux at all; (WTF) - if any1 here pays for a Pro license, please contact them and reference this

[fermulator]

I scanned past all the commits and stumbled over this

104bdd3
(one would think this would IMPROVE CPU usage ... but am suspect of it)

how to disable hardware acceleration in the AppImage? hmmm

[vladimiry]

how to disable hardware acceleration in the AppImage? hmmm

Try passing some of the following CLI args (or all of them):

• disable-gpu
• disable-software-rasterizer

Like ./app.AppImage --disable-gpu.

[fermulator]

Thx @vladimiry , 'twas simple enough. Tried both, had no affect on the CPU for this issue (as kind of expected), so that delivery is not related to this performance regression.

[vladimiry]

@fermulator there are a lot more switches you could also try :)

[fermulator]

Open to trying to isolate, but that is too wide a spread. Really would appreciate maintainer/dev direction here on potential ways to root cause.

[ghost]

Wire Helper: constant 6% CPU, Wire: constant 3% CPU. (MacOS Mojave)

[Mikaela]

Adding to #2507 (comment), I have since learned that Chromium's sandbox doesn't work in Flatpak currently, so it has to be disabled.

I have also since enabled full MDS mitigation (mds=full,nosmt) which disables hyperthreading and makes two CPU cores "disappear" (as they apparently never existed in physical reality) so I think this may be affecting me more.

[AJolly]

Similar high CPU utilization in Windows.

[fermulator]

How do we get wire staff to pay attention here? 6 months later ... is this never going to be fixed?

[ffflorian]

Hi folks, trying to nail this issue down.

First thing: 2-4 % background CPU usage is normal for Electron apps. A spike to 10 % might come from incoming messages or outrunning timed messages.

Further questions:

• did it help disabling GPU for Wire?
• did you see other Electron apps with this behavior? If yes, which Electron version were they using?

[wilhelmy]

One of the Wire processes in htop eats 8% CPU here, whereas Signal (also Electron based) eats about 2% peak (about 0.6% on average).

I didn't try disabling GPU yet. This is on Linux. I didn't want to jump to conclusions out of whatever kind of UNIX elitism bias I might have and give Electron apps a fair chance but if this is expected behaviour on Electron I have my doubts now.

For reference, Wire is the difference between the laptop fan constantly spinning and not spinning at all on idle on my machine and firefox with hundreds of tabs uses less resources than Wire...

[AJolly]

It's eating about 7% on a overclocked 4.7ghz 10 core machine. Signal is at 0%. The larger your wire history, the worst it gets.

[fermulator]

@ffflorian my posting earlier shows the results w/ GPU disabled
EDIT: for all the possible flags/params to troubleshoot with I could try a few, but not sure how these work within AppImage launcher ... it doesn't work

/home/fermulator/bin/wire-3.5.2881-x86_64.AppImage --disable-gpu

ps wauxxx | grep AppImage
# doesn't show that flag passed through

Indeed I have also used other Electron apps (i.e. Slack) and it does not suffer from this.
Further to @wilhelmy stated, for me too if Wire is open, CPU is hot, fan spins - it is degrading our battery and hardware.

[fermulator]

Per noted in #3338, interestingly it IS true if you minimize to tray the excessive CPU is reduced (suggesting indeed we have an aggressive refresh/activity graphically that gets paused while minimized).

• 5-8% while open in background idle (no active messages)
• ~2% while minimized (no active messages)

[wilhelmy]

2% when idle is still high, to be honest. Signal is at 0.6% when idle with the window still open.

[electronstudio]

On MacOS I'm seeing >6% when the window is open and 3% even when the window is closed. No way is that acceptable for an app that shouldn't be doing anything except waiting for message to arrive.

[liskin]

Also still happens with app.wire.com in latest Chrome on Linux. No other tab consumes as much CPU as Wire.
Any chance this will ever get resolved?

[fermulator]

If April 2021 hits, it will have been 2 years since this perf regression bug, being unfixed. If not fixed by then I'll be abandoning wire. @ffflorian

[alien2003]

7You are lucky getting just 6-7%, I get 13-15% on my Surface Pro 6 (i7/16GB)

[xavim86]

Hi, I am having the same issue in Linux. I am experimenting with the command cpulimit trying to see if there is a reasonable way to idle-ize and de-idle-ize the wire-desktop processes ... I am not an expert at all. So far I could list the processes involved using

ps aux | grep wire-desktop | awk '{print $3,$2}' | sort -r

then I pick the PID of the process with largest cpu load from the previous command and do

cpulimit -l 1 -p PID_OF_THE_PROCESS

It seems to calm down the cpu load. It's not a nice mitigation ... but maybe someone could improve this further? Thanks in advance!

[fermulator]

@xavim86 - note that if you CPU limit ... while this might help stave off the idle CPU, would this not stifle wire from performing "actual work" while in use? (i.e. voice or video calls)

[xavim86]

@fermulator - yes, you are right. My current (horrible) way to deal with Wire cpu load is to have one script to idle-ize processes names "wire-desktop" using cpulimit and let it run 'limited' for the notification icon to change thus indicating that some new message arrived or somebody calling me. Then, I de-idle-ize Wire with another script that kills the involved "cpulimit" process so that the program runs smoothly again. This is not practical at all and does not make me happy! I wish this would be solved in future updates of Wire Desktop...

[fermulator]

Given the age of this issue, and lack of official wire developer or support commitments to fix, I have no reason to believe it will ever be fixed at this point. :(

[dbquarrel]

I started complaining about CPU use in 2017.

Nothing will ever be done.

Look how hilarious this looks on an M1 Macbook.

Wire is doing nothing and just burning that CPU. It's the renderer helper processes, just sitting there I guess drawing the same data forever in a loop with 30+ threads each.

I just can't get through my head that someone has actually designed this to behave like this.

[liskin]

Inspired by #2239 (comment) I took a closer look and indeed there is a loading spinner somewhere in the page, hidden inside a couple of display: none elements yet repainted at 60 fps nonetheless. I ended up with this uBlock filter:

app.wire.com##div.loading-wrapper:remove()

Now the https://app.wire.com/ browser window consumes much fewer resources. Unfortunately this doesn't really help the poor people who choose to run Wire in Electron as there's no uBlock in there. :-/

Anyway, I'll try reporting the issue to Chromium, so maybe this will get fixed in a couple years.

[bennycode]

@liskin the div class="loading-wrapper" comes from our web app code. How much CPU does it save you when you remove it?

[liskin]

@liskin the div class="loading-wrapper" comes from our web app code. How much CPU does it save you when you remove it?

Before I removed it, the tab would consistently consume 10 % CPU on my i7-7500U. When I add that uBlock filter, it stays at zero.

[liskin]

Reported to Chromium here: https://bugs.chromium.org/p/chromium/issues/detail?id=1206425
Also seems to be reproducible in Firefox so it'll be better to fix this on Wire's side as well.

[dbquarrel]

@liskin do you know if it's been reported to Mozilla yet? They are pretty responsive about bugs and would want to know. If not I'll try to do a report over there.

[liskin]

@dbquarrel I didn't look there, feel free to go ahead. :-)

[Siguza]

Getting the same behaviour on an M1 Mac mini, macOS 11.4. The Wire Renderer constantly has 10-20% CPU usage, even when idle and off-screen (i.e. on a "desktop space" other than the current one).
I sampled the process, not sure if this tells you anything:

Sample of Wire Helper (Renderer).txt

[JMoVS]

I started complaining about CPU use in 2017.

Nothing will ever be done.

Look how hilarious this looks on an M1 Macbook.

Wire is doing nothing and just burning that CPU. It's the renderer helper processes, just sitting there I guess drawing the same data forever in a loop with 30+ threads each.

I just can't get through my head that someone has actually designed this to behave like this.

same for me. Whereas slack was a hog in the past, I don't see slack anymore in my list - Wire on the other hand...

[JMoVS]

does a debug archive/log help?

[jviide]

Pull request #5164 attempts to remove the LoadingSpinner contents from the DOM after the spinner has faded out. It seems to lower the idle CPU usage considerably - at least on Macs.

[fluffypony]

I suspect that part of the issue on M1 Macs is that it's running under Rosetta 2. I have NO CLUE why there is no Universal Binary / Apple Silicon binary of Wire Desktop when we're nearly in 2022.

[alien2003]

I suspect that part of the issue on M1 Macs is that it's running under Rosetta 2. I have NO CLUE why there is no Universal Binary / Apple Silicon binary of Wire Desktop when we're nearly in 2022.

We don't even have Linux ARM version. ARM Linux runs on a lot of hardware (laptops, tablets, smartphones, single board computers) and you are talking about Mac ARM which is niche of niches - only few laptop models from single vendor

[dbquarrel]

On Mon, Dec 20, 2021, at 15:01, alien2003 wrote: > I suspect that part of the issue on M1 Macs is that it's running under Rosetta 2. I have NO CLUE why there is no Universal Binary / Apple Silicon binary of Wire Desktop when we're nearly in 2022. > We don't have even Linux ARM version. ARM Linux runs on a lot of hardware (laptops, tablets, smartphones, single board computers) and you are talking about Mac ARM which is niche of niches - only few laptop models from single vendor

To clear some misconceptions in your note here: 1. all of Apple's laptops are now M1 ARM: (Air and Pro models both, Apple will no longer make Intel based laptops) 2. Apple's Mac Mini has transitioned to M1 ARM 3. Apple's iMac 24" has transitioned to M1 ARM This leaves Apple with two Intel based products, the Mac Pro (if you want to use the word "niche" there must be only one of these sold for every thousand laptops or something like this), and the iMac 27" (which will almost certainly follow the 24" during the next product refresh). So, reality is that M1 ARM is the default architecture for Apple at this point. Treating Intel as the default architecture is wrong and calling it "niche of niches" is misinformed. Lastly, compiling for M1 is literally adding a compiler flag. Wire's development group is traditionally looking at the wrong thing, for instance it took the community four years of hassling the developers about CPU use being extremely high while the app is idle, to have these responses: a. silence b. we will look at it at some point c. closing threads It took the user community to solve the CPU issues in the end. If now the community is going to have to educate about what Apple is using for their hardware, we're into another four years of this. That said, Rosetta 2 is extremely effective though a native compile is much, much better. Having recompiled all of my own code for M1 simply by checking off a box in Xcode and having no problem, with some of my code authored as far back as 1988 in C, and using a mix of C, C++, Objective-C and Swift, I find there is little to no excuse for anyone to claim that M1 is niche of niches and so acceptable to ignore. Furthermore the architecture is already supported via iPhone builds which have existed since the beginning. Ignoring M1 is not the approach of Adobe, Microsoft, etc. Yes we will always have an ocean of Intel based products that will always be everyone's focus, but the point here is that M1 is more important than is claimed and should not be ignored.

[fluffypony]

@dbquarrel nailed it. In addition, Wire already has an ARM build for Apple devices - the iOS version! In fact, they could opt-in to the iPad version being available in the M1 App Store, without needing to recompile or do anything, but instead have chosen to purposely disable this. Some apps (eg. Plex) allow for both the macOS and iOS versions to be used on Apple Silicon whilst they're transitioning to a single, unified application.

In addition to it largely being a compiler flag, all of the fundamental bits and pieces for Wire Desktop have had M1 support for a significant period of time precisely because it is not a "niche of niches". Electron, for instance, has had M1 support since November 2020, 5 major releases ago.

[fluffypony]

New version is FINALLY in the App Store with the patch for this, THREE YEARS after it was patched.

Still not a universal binary, but at least it's no longer hammering at battery life for no real reason.

[fermulator]

Can confirm; Issue is now resolved. (Linux)

Version 3.28.2946
Wire for Web Version 2022.09.20.08.41