Closed rawlife56 closed 2 years ago
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
I also report similar CPU vs. chat behaviour. It doesn't seem to matter which conversation the app sits idle in.
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.
Same here, it constantly eats 9% CPU. I've quit it for now, this is unreasonable.
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.
I am having the same issue. Getting 15% cpu usage when idle and 75% cpu usage when focusing the application.
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?)
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
I scanned past all the commits and stumbled over this
https://github.com/wireapp/wire-desktop/commit/104bdd3ba0ba8dc1c296ed646e670a95f3e72bb4 (one would think this would IMPROVE CPU usage ... but am suspect of it)
how to disable hardware acceleration in the AppImage? hmmm
how to disable hardware acceleration in the AppImage? hmmm
Try passing some of the following CLI args (or all of them):
Like ./app.AppImage --disable-gpu
.
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.
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.
Wire Helper: constant 6% CPU, Wire: constant 3% CPU. (MacOS Mojave)
Adding to https://github.com/wireapp/wire-desktop/issues/2507#issuecomment-495508674, 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.
Similar high CPU utilization in Windows.
How do we get wire staff to pay attention here? 6 months later ... is this never going to be fixed?
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:
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...
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.
@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.
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).
2% when idle is still high, to be honest. Signal is at 0.6% when idle with the window still open.
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.
Is anyone affected a paying premium subscriber or do they know someone? - Based on what I've seen here in terms of issue activity, and the response from wire-support -- they will not fix this unless complaints are received from paying customers.
I also experience constant idle CPU usage of around 10 % (little variation). This is on macOS 10.14.6. It was not an issue under macOS 10.13.6 with the same version(s) of Wire three days ago. In fact, in the ~ 2 years I've been using Wire for macOS, idle CPU usage was always practically nil, as it should be. Now it is by far the most CPU-hungry of all background processes on my system, eating more CPU time on average than kernel_task and considerably draining the battery on my laptop. I have to stop running the app for now and only launch when I get a notification on my phone. Not good.
The issue was almost certainly triggered by the macOS system update from 10.13 to 10.14 – no Wire update took place in the meantime.
The CPU usage is mostly from two helper processes:
It doesn't matter which conversation is selected or if the Wire window is active, frontmost, closed, or hidden.
I notice that all mention of the free, personal-use version of Wire has been removed from the official website. I hope this and the ongoing neglect for this issue does not indicate that the free version is being phased out. Security and usage-wise, it is the only messenger app that accomodates my needs.
Wire Version 3.12.3490 Wire for Web Version 2020.01.13.1120
I'm seeing the same thing described by @Shnub above, a recent increase to about 15% constant CPU core use on a MacBook Air. It happened around the same time that I updated to macOS 10.14 Mojave. In the previous years I've used it, it has been less than 5% when idle. It doesn't matter whether the app is hidden or not. This is probably a different issue than the other reports about Windows/Linux.
It's no longer practical to keep it running in the background as I always have. It has a noticeable impact when watching video, web browsing, etc., and causes extra heat, fan activity, and battery drain.
Also echoing the other comment - you could have left the free account as a great alternative to What's App, Telegram, SMS, iMessage, etc., for client and customer communications by and between freelancers and small businesses, while using that as a freemium lead-in to paid "pro" Slack-like accounts for internal teams that you're emphasizing now. I used to recommend a free Wire account as the best way for business customers to contact me. But since it changed to "personal-use only", and now has been removed from the website, it just looks unprofessional for me to recommend it, even though there's nothing technically changed with Wire and the fact that it doesn't require people to give you their personal phone number is a major advantage. Such a shame, and hard to understand why you would prohibit freelancers and small businesses - the very people you want to attract as paying customers - from using Wire as an alternative to other free messaging apps.
Version 3.12.3490 Wire for Web Version 2020.01.13.1120
Can confirm the issue, Wire is using way too much CPU in closed state:
MacOS 10.15.4 Wire 3.15.3621
@ffflorian - anything the community can do to help assist/isolate the problem? -- based on the above historical trail, we clearly have a regression here, enough users have reported the issue, across multiple platforms;
to be bold: this regression is negatively impacting the environment
Still an issue with Wire 3.18.3728 on macOS 10.15.5. I'm getting about 10% CPU usage while idle. For comparison, Caprine (which is another electron app - a web wrapper for Facebook Messenger) uses almost no CPU while idle (between 0.1% and 1%).
@tech189 do you know which Electron version is used in your Caprine installation?
We will check if an update to Electron v9.1.0 will bring better performance since it includes a fix for intermittent 100% CPU usage on macOS.
Caprine currently uses Electron v9.0.5 Thanks for looking into it!
@fermulator
- how can we check which version of electron is in place for a given version of wire messenger?
Please see the Builds page for that.
I just tried upgrading off the appimage train to debian apt pkg management https://github.com/wireapp/wire-desktop/wiki/How-to-install-Wire-for-Desktop-on-Linux#installation-on-debian-based-distributions
This gave me:
Wire Version | Chrome Version | Electron Version | Release | Download |
---|---|---|---|---|
3.19.2928 | 83.0.4103.122 | 9.1.2 | 2020-08-05 | deb / AppImage |
Wire is still consuming the same amount of CPU/waste.
So Since we're on 9.1.2
electron, presumably this has not addressed the problem.
I don't think this is an Electron issue, since I'm seeing the same on the web app (Chrome 85.0.4183.83 - latest stable)
Electron ≈ Chromium ≈ Chrome (with certain differences).
Could be tested the webapp in other web browser to see that is not general in Chromium?
Tested in Firefox. Took a while because Wire doesn't import history in new clients and I had to wait until the conversation was long enough.
I don't quite understand Firefox's task manager, but in a conversation with probably a couple thousand messages the "energy impact" is constantly hovering around "medium" and the tab is consuming over 200MB. On Chrome I see about the same behaviour, with longer conversations reaching almost 1GB of memory usage.
What I've also noticed is that the performance tends to get worse the more you chat, to the point that the UI starts getting unresponsive and I need to reload the entire web app.
Possibly one more lead: Wire Helper (Renderer)
going to 40%-50% of CPU usage when it was on background (just running) on macOS.
When I've switched to wire, it has this on the screen:
Restart helped.
On Arch Linux/Gnome, Wire's /usr/lib/electron10/electron --type=gpu-process
uses about 10% of a CPU core constantly for me, and one of the /usr/lib/electron10/electron --type=renderer
processes uses about 30%.
Restarting doesn't help.
Doesn't matter what's being displayed in the window: an empty chat, the settings screen, or a group chat with a long message history, the CPU usage remains the same. Closing the Wire window but leaving it running as an AppIndicator doesn't reduce the CPU usage either.
Installed package is community/wire-desktop 3.21.2936-2
.
Running wire-desktop --devtools
and using the profiler I see nothing under Event Log, nothing under Call Tree. There's just a small amount of GPU activity, around 1% of the time. Not sure what else to check to diagnose this.
Ubuntu 20.04.1 LTS Wire Version 3.21.2936 wire windows closed, only in backgrond constant CPU churn of 6-8% from proces with --type=renderer and a little (2%) from from --type=gpu-process. Our own app based on Electron 10 while in foreground does not do this
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?
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
7You are lucky getting just 6-7%, I get 13-15% on my Surface Pro 6 (i7/16GB)
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!
@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)
@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...
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. :(
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.
Wire version: 3.9.2895
Wire for web version: 2019.04.10.0901
Operating system: Linux (Arch-KDE)
What steps will reproduce the problem?
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-
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.
'