search

status-im / status-desktop

Status Desktop client made in Nim & QML
https://status.app
Mozilla Public License 2.0
296 stars 78 forks source link

App constantly uses 15% of CPU and 15% of GPU on mac when IDLE #3006

Closed flexsurfer closed 3 years ago

flexsurfer commented 3 years ago

run the app with a few not really active chats, wait until all messages are fetched look at the cpu and gpu usage , App constantly uses 15% of CPU and 15% of GPU on mac when idle , for me as a user its a blocker

it happens on the new account without chats as well

gpu drops to 0 and cpu to 4% when app is in background

anastasiyaig commented 3 years ago

I remember we saw similar issues , @michaelsbradleyjr @iurimatias ? I dont see such numbers Andrey mentioned, however it could be different based on the processor, i am using M1

anastasiyaig commented 3 years ago
Screenshot 2021-07-21 at 23 02 54

here is the stats i do have now, i am running desktop and mobile

flexsurfer commented 3 years ago

image

gpu drops to 0 and cpu to 4% when app is in background, so it seems it's rendering something?

flexsurfer commented 3 years ago

it happens on the new account without chats as well

pinebit commented 3 years ago

May be related https://bugreports.qt.io/browse/QTBUG-84327

flexsurfer commented 3 years ago

yes I'm using 4k external monitor, just tested without it, no difference

pinebit commented 3 years ago

yes I'm using 4k external monitor, just tested without it, no difference

I don't think this has something to do with an external monitor. I think this is a combination of Qt version and XCode version. But I am not a Mac expert, so leaving this to experts who actually works on Mac.

anastasiyaig commented 3 years ago
Screenshot 2021-07-23 at 10 13 22

Crazy CPU usage after i get the laptop from sleep

iurimatias commented 3 years ago

@flexsurfer do you happen to be using a very old data folder? (say, 6 months)

iurimatias commented 3 years ago

it happens on the new account without chats as well this is particularly confounding 🤔 the problem is that we can't exactly replicate this so we need more info to try to pin it though what is different in your setup / circumstances that could cause this so we can replicate, some questions:

flexsurfer commented 3 years ago

image

so I wiped all data and made a fresh install, latest master StatusIm-210723-214423-39dace-prnull.dmg, no other versions are running, no other status-go instances, no external monitors, just clear install and run, create a new account and look at the cpu, its the same ~20% of cpu and gpu

flexsurfer commented 3 years ago

i've been reporting this issue for at list half a year now, so its not a new issue

saledjenic commented 3 years ago

I've been testing this multiple times, an observation using newly created account each time is: When the app is starting CPU usage knows to reach 65%, but only for a few seconds, after that it drops to 15% and after like 10-15 seconds it normalizes itself and CPU usage varies between 7.5 and 10.5%. That's the case when nothing is added, just bare app is running (no chats, wallet, communities, dapp browser and so) and the app is an active window all the time. If I move the app to the background CPU usage drops to below 1% (like 0.3 - 0.5%) and moving it back to the foreground CPU usage easily increases to, as I mentioned, 7.5-10.5%.

So in any case I was not able to reach 20% of CPU usage (tested on BigSur, version 11.1, 2.6 GHz 6-Core Intel Core i7), but anyway average CPU usage of ~10% for an empty app is maybe too high.

With everything enabled and added two chats added (one public and one private) CPU in my case is ~15%.

Reasons for high CPU usage may be different:

  1. unoptimized code
  2. having some hard processing in the main thread
  3. nested updates (e.g. exposing property (which is a list of items) and exposing properties for that item, then when we need to update such architecture there is no need to send signal for each property of the item, it's enough when the data are set to emit just a single signal for the list property)
  4. resetting whole model instead of updating exact item from model
  5. we're running background logic and maintaining UI even it's not displayed (this is the case for all parts which are off by default like wallet, dapp browser, communities, activity center and so). Instead we should initialize that parts only if user turns them on (do sort of lazy initialization). That will reduce lot of CPU and memory usage, cause so far we initialize everything what app contains at the app start (like for any case) regardless we really need that or not.

One big obstacle is that we cannot use any profiler/analyzer like this: https://doc.qt.io/qtcreator/creator-cpu-usage-analyzer.html

flexsurfer commented 3 years ago

hey, @saledjenic thanks for the research, yes it varies between 7 and 15% for me, usually, it's 12%, but why does it use GPU ? also 12%?

saledjenic commented 3 years ago

@flexsurfer every Qt/qml app is running by default on integrated GPU and depend on OpenGL, they are painted using GPU. We have a lot of qml components, also lot of animations in the app which use both CPU and GPU, but all in all I am not sure about the percentage, is 20% too high or not, is it for a moment or two like that and then drops or not, in my cases it doesn't go above 8% of GPU.

flexsurfer commented 3 years ago

i mean, there is no animation or any complex components, the app is idle, doing nothing, it shouldn't use GPU

iurimatias commented 3 years ago

Hey @flexsurfer , there is now a likely fix for this in PR #3081 but first I would like to provide some context for this and what to expect of CPU usage in different contexts:

The issue itself was introduced in this commit https://github.com/status-im/status-desktop/commit/dc9de1968fb6924fedd962f8ec47371a7b8dbfa0 on march 25.

Looking at activity monitor isn't very reliable sometimes as it can fluctuate a lot, the best is to look at the usage over a period of time, for that we created a script to measure this (can be found here https://gist.github.com/iurimatias/ae0896e3d54fd635d4baa773fc206d44 , very hacky but it works), and with it I could verify this issue was happening and this was the commit where the cpu usage definitely became much higher.

Before that commit: average cpu usage: 2% minimum 0.6% After that commit: average cpu usage: 12% minimum 6.8%

now with the fix on master/3081: average cpu usage: 1.5% minimum 0%

So it's a definitive improvement. It's important to also understand the different situations (as the words 'idle' sometimes mean different things to different people depending on the context)

Background

here we're getting according to last I measured

{ cpu_per: 0.8899999999999989,
mem_per: 2.300000000000005,
vsz: 6190531.633333334,
rss: 394075.1666666667,
cpu_min: 0,
cpu_max: 10.1

Background Idle

So the app is in the foreground but the user is not doing anything, so it's "idle"

{ cpu_per: 1.4983333333333326,
mem_per: 2.300000000000005,
vsz: 6190509.7,
rss: 393817.8333333333,
cpu_min: 0.6,
cpu_max: 18.1 }

Foreground active Here I got these results, which are actually pretty good

{ cpu_per: 5.599166666666667,
  mem_per: 2.400000000000001,
  vsz: 6217631.5,
  rss: 407376.93333333335,
  cpu_min: 0.7,
  cpu_max: 15.6 }

When an app is in use, it will use a lot more CPU, I verified this happens with other apps as well so it is to be expected

for example discord:

https://user-images.githubusercontent.com/176720/127223276-fbe84a79-de49-4219-abd7-63fd36833fc3.mov

discord is electron so it kinda sucks, but even Telegram that is in C++/Qt has high usage with normal usage:

https://user-images.githubusercontent.com/176720/127223388-028c3518-833e-4cb8-9dcb-deca34f0aa7e.mov

in our case I got this:

https://user-images.githubusercontent.com/176720/127223423-3e73b2ca-39c2-42b0-87ef-a59137a9d641.mov

flexsurfer commented 3 years ago

thank you @iurimatias and @pinebit can confirm the issue is fixed in the latest master, my issue was about Foreground idle - app is in the foreground but the user is not doing anything at all, @pinebit could you please explain what was the issue, so we have info here for a future? thanks

pinebit commented 3 years ago

thank you @iurimatias and @pinebit can confirm the issue is fixed in the latest master, my issue was about Foreground idle - app is in the foreground but the user is not doing anything at all, @pinebit could you please explain what was the issue, so we have info here for a future? thanks

We still need to investigate this further, but at the first glance the issue appears in the application initialization flow. I suspect some odd background activities that were not stopped when transitioning from the login to the main state.