hiqua
commented
3 years ago Are you really using v5.7? Can you update if that's the case?
Closed wohltat closed 1 year ago
hiqua
commented
3 years ago Are you really using v5.7? Can you update if that's the case?
wohltat
commented
3 years ago Oh, it was from the ubuntu repos.
Now i'm on v5.12.2 but i see the same behaviour. Mostly 4%-5% CPU usage after start and minimized.
hiqua
commented
3 years ago From your logs, I'm not sure where you read 4 to 10%, but even then, there's no baseline which Signal-Desktop should reach (FWIW it's always less than 4% on my computer according to htop). The lower the better, and whatever can be done to lower this should indeed be done, but there's little that's actionable from this issue.
wohltat
commented
3 years ago i read the cpu usage from htop as well. Btw i just kept it running without changing anything and it now is around 8% cpu usage. There are multiple signal-desktop processes in htop and if i add thier cpu usage i even get a lot over 10%.
There maybe no objective baseline. But for me subjectivly this is too much. I lot more such idling applications and the cpu (or one cpu) is fully loaded. What is it that signal-desktop is doing if there is nothing happening. Other messengers don't need that much resources. For comparison, my email client uses 0.0% when idling according to htop, just like every 10 seconds there is a spike of 1% or so.
As i said i also don't really know what to make of the strace/ltrace logs. This was just a starting point. I don't know any other way to see what signal-desktop is doing other that study the code.
What is your cpu usage? Maybe there is something special with my setup if other people don't see this behavior.
wohltat
commented
3 years ago Also another way to look at the cpu usage is, not to compare it to the 100% possible but to the rest that is currently used.
When my computer is idle and im reading a website(and other apps closed) i have roughly 4% or less on each of the 4 CPU cores. If an app uses 8% than it is already half of what all other processes are using. Therefore this makes a huge difference how long my notebook battery lasts if i'm just reading.
hiqua
commented
3 years ago Can you add a debug log?
wohltat
commented
3 years ago This is the debug log: https://debuglogs.org/893b0931083dc697fff52a7f318051f736c3832ab34a8cb2f539aa7ae734a378.gz
josh-signal
commented
3 years ago @wohltat we believe this is fixed in 5.13.x can you please upgrade?
wohltat
commented
3 years ago There seems to be an improvement. Shortly after start of signal-desktop there is around only 1% cpu usage.
But after ten minutes or so, it looks almost like before. So it didn't change much.
wohltat
commented
3 years ago I had a closer look when the increase in cpu usage happens. I started signal 10 times and after a bit over 2 minutes the cpu usage was rising significantly. This behaviour was consistent over all trials.
The last four times i looked at the time even closer and it was pretty much exactly 2:07min after signal was launched.
Could it be that there is some timer that is initialized on program start (7 seconds after launch) that triggers something after 2 minutes?
wohltat
commented
3 years ago I started signal at 20:35:01. in the log there is
{"level":30,"time":"2021-08-12T20:37:07.824Z","pid":1793148,"hostname":"computername","msg":"attachment_downloads/_maybeStartJob: no attachment jobs to run"}
{"level":30,"time":"2021-08-12T20:38:00.280Z","pid":1793148,"hostname":"computername","msg":"WebSocketResources: Sending a keepalive message"}
{"level":30,"time":"2021-08-12T20:38:07.825Z","pid":1793148,"hostname":"computername","msg":"attachment_downloads/_maybeStartJob: no attachment jobs to run"}
{"level":30,"time":"2021-08-12T20:38:09.558Z","pid":1793148,"hostname":"computername","msg":"getAllFromCache"}
{"level":30,"time":"2021-08-12T20:38:09.562Z","pid":1793148,"hostname":"taschenrechner","msg":"getAllFromCache loaded 0 saved envelopes"}
i tried again at 20:43:00
{"level":30,"time":"2021-08-12T20:45:05.613Z","pid":1794853,"hostname":"taschenrechner","msg":"attachment_downloads/_maybeStartJob: no attachment jobs to run"}
{"level":30,"time":"2021-08-12T20:45:08.547Z","pid":1794853,"hostname":"taschenrechner","msg":"getAllFromCache"}
{"level":30,"time":"2021-08-12T20:45:08.552Z","pid":1794853,"hostname":"taschenrechner","msg":"getAllFromCache loaded 0 saved envelopes"}From exclusion and because other message have been there before, the rise in CPU usage could be connected to
"getAllFromCache" and "getAllFromCache loaded 0 saved envelopes"
whatever that means.
indutny-signal
commented
3 years ago Hah, very interesting. Could you post your debug log or send it over email to me (indutny@signal.org)?
I'm looking for something like: "slow query getUnprocessedCount" or "slow query getAllUnprocessed", but it might be something else!
indutny-signal
commented
3 years ago Nvm, it loaded zero saved envelopes. Interesting...
indutny-signal
commented
3 years ago This code path runs every 2 minutes. Do you see CPU spikes every 2 minutes or just once 2 minutes after app restart?
wohltat
commented
3 years ago I haven't figured out the pattern just yet. I'm about to make a recording of the CPU usage.
Sometimes its low for a while and then its high for at least several minutes. What i find interesting is, that it if signal is maximized and then minimized again, it goes to low cpu usage quite reliably. But after minute or so (seems to vary) goes up again.
wohltat
commented
3 years ago I don't know why but now the behavior is different. The rise in cpu usage is not appearing after 2 minutes but later.
Here is a plot of the 1 minute average CPU usage over some hours. The CPU load of all signal processes where summed up. At the end you can see the phenomenon that the cpu load drops when minimizing signal. @indutny-signal i sent you the debug log that should correspond to the plot.
Code to create the plot:
from pylab import *
import pandas as pd
import psutil
import time
from time import sleep
sp = [p for p in map(psutil.Process, psutil.pids()) if p.name().find('signal-desktop')!=-1]
cpu_usage = []
while True:
cpu_usage.append([time.time()] + [p.cpu_percent() for p in sp])
sleep(0.1) # 0.1 = 100ms resolution
# manually interrupted the loop here after some time
%pylab notebook
# code for plotting the results
df = pd.DataFrame(cpu_usage, columns=['time'] + [p.pid for p in sp])
x = pd.to_datetime(df.time * 1e9) # time in ns
cpu_usage_all_processes = df.iloc[:,2:].sum(axis=1)
y = cpu_usage_all_processes.rolling(10*60).mean()
h = plot(array(x), array(y))
_ = plt.xticks(rotation=45)
ylabel('CPU usage [%]')I'm not entirely sure what's going on. The logs that you sent to me doesn't show any activity during that time on our end. The most work that we've done at that point was running a db query once per minute and sending a keepalive message to the server once per minute too. The query didn't take long time to run, and keepalive is generally inexpensive so I don't see how any of these could have triggered a high-CPU usage.
Did you happen to have a conversation open with GIFs running, or something that would use a lot CPU power to redraw UI often?
wohltat
commented
3 years ago There wasn't anything happening and nothing open until around 10:45 when you can see a bit of turbulence in the graph.
I can do a long time recording of the cpu usage similar like the one i posted if this would help you.
alien2003
commented
3 years ago Happens for me too, Drains battery a lot
indutny-signal
commented
3 years ago @wohltat we just released 5.14.0 which has some fresh performance improvements. Could you give it a try and see if it helps at all?
wohltat
commented
3 years ago Updated to v5.14.0. Looks very similar to me.
chmike
commented
3 years ago I have 5.13.0 installed on Ubuntu 21.04 and also see 10% CPU usage while Signal is idle. That is too much. It's 3 times more than firefox that I currently use to write this comment.
Why is the issue closed ? The problem is not at all resolved. Edit: after some tests I found out that there is no such CPU usage after a fresh restart of the app. The problem thus shows up after receiving and sending messages for some time. Indeed, after sending a message, the CPU usage raises from 0.7% to 1.5-2%. After receiving a message, the CPU usage raise again and is now 4%. Such a CPU raise with only two message exchanges.
scottnonnenberg-signal
commented
3 years ago @wohltat @chmike @alien2003 What we need is more information from you - we need you to be scientists. What I see when Signal Desktop is in the background is 0.1-0.3% CPU usage, so details from your configuration are really important.
I've opened the issue again - please let us know everything you can about how the behavior changes. The increase over time as the app is used after startup is really interesting. Does it change if you close the conversation with Ctrl+Shift+C to close the current conversation so no conversation is showing? What if you don't send any messages, just open a conversation with 30+ messages in it? How about opening a conversation with no messages in it?
That's the kind of information that may lead to a fix. Thanks!
wohltat
commented
3 years ago Here is another recording.
I did not interact with signal-desktop in that time. I just opened some messages on my phone several times which did not seem to interfere.
There were no open conversations, i.e. closed with "Ctrl+Shift+C".
Couldn't we go more in the direction of the core, i.e. incorporate a debugger or use strace/ltrace? I'm trying but i'm just learning to do that. Is the info of my first post telling you something?
>> sudo ltrace -p $(pgrep -x "signal-desktop" | cut -f1 -d' ' | head -1) -c
^C% time seconds usecs/call calls function
------ ----------- ----------- --------- --------------------
46.31 21.677400 7842 2764 epoll_wait
25.65 12.007795 4144 2897 __errno_location
16.49 7.717917 3868 1995 clock_gettime
5.13 2.400149 1200074 2 g_main_context_iteration
...There is info on my system in the initial post. Which additional info do you need?
wohltat
commented
3 years ago What we need is more information from you - we need you to be scientists. What I see when Signal Desktop is in the background is 0.1-0.3% CPU usage, so details from your configuration are really important.
@scottnonnenberg-signal What would you do if if this would happen on you computer? Which tools would you use? So far if never seen a CPU usage below 1%. Although i think this high for a idling app, i would be pretty happy already if it would not go higher than that.
I made another longer test. The interesting thing is that this time it was low for several hours. Then i opened signal, opened some conversations, ctrl+shift+c and then minimized it again. After that cpu usage stayed high again. You can see that the rise happens approx at 15:10:45. The logs are linked below
complete logs: https://debuglogs.org/60974014ee8aed91149385b1b99463f2ed0404f0774b4c38b77b39d91c53683b.gz
scottnonnenberg-signal
commented
3 years ago What would you do if if this would happen on you computer?
I'd use the dev tools profiler. If you start Signal Desktop with --enable-dev-tools you can open it up and see what's using resources. Open the 'Performance' tab, uncheck 'screenshots' and then hit the circle button. Then let the app go idle, not opening anything. Come back after a couple minutes, then send the resultant trace to us. Feel free to send it to me directly. That'd give us a good baseline for what's happening in the background on your machine.
chmike
commented
3 years ago When I try to start signal on the command line with --enable-dev-tools, this is what I get:
$ signal-desktop --enable-dev-tools
NODE_ENV production
NODE_CONFIG_DIR /snap/signal-desktop/370/opt/Signal/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME undefined
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/meessen/snap/signal-desktop/370/.config/Signal
config/get: Successfully read user config file
Set Windows Application User Model ID (AUMID) { appUserModelId: 'org.whispersystems.signal-desktop' }
x-attr dependency did not load successfully
config/get: Successfully read ephemeral config file
making app single instance
quitting; we are the second instance
Erreur de segmentation (core dumped)The signal app in the tray is started though.
wohltat
commented
3 years ago @scottnonnenberg @indutny-signal I sent you the signal profiler logs. Those are two files corresponding two the states of either low or high cpu usage that you can see in my previous plots. Thanks for the hint to the dev-tools. Looks like a very nice and powerful tool.
I don't know the inner workings of signal but there are some things that look very suspicious to me: There are, besides some other stuff, two periodic events that occur most of the time.
ringrtc/Service.js:149: roughly 0.5ms every 50ms preload.bundle.js: roughly 0.3ms every 100ms
First question. Is it really necessary to run these events that frequently, 10Hz and 20Hz? Furthermore, do these functions really do that much. On the processor 1ms is like millions of operations. Sounds quite a lot to check if new messages have arrived. As far as i understand the RTC is for RealTimeCommunication. But when idling there is no real time communication like voice or video, correct? The RIngRTC service looks the most suspicious. One thing is that when i read "pollEvery" i think of polling as a great way to burn CPU resources. Second thing, why is there a "timer install" every 50ms? The timer id also increments by 1 every time. Doesn't look right to me to create a timer every 50ms.
So far i haven't found what is the difference between low and high cpu usage stat though. Before i started the recording and after stopping the cpu usage was high. But i can't say for sure if it was while the recording since i could not separate the dev-tools profiler usage from the rest, i.e. both is a signal-desktop process.
wohltat
commented
3 years ago if you want i can also try some development versions. I know how to handle git and how to compile stuff if this makes it easier for you.
wohltat
commented
3 years ago @chmike i guess there is an other instance running already. Try closing all signal-desktop processes before.
quitting; we are the second instance Erreur de segmentation (core dumped)
chmike
commented
3 years ago I managed to run with the development panel. But the CPU monitoring is not accurate. With top I see one process using 10% CPU. There are currently 9 signal-desktop processes, but only one uses 10% cpu. It has now raised to 16% after measuring performances.
This is the process that burns CPU: 9671 9535 18 09:31 pts/3 00:10:31 /snap/signal-desktop/370/opt/Signal/signal-desktop --type=renderer --no-sandbox --field-trial-handle=12894220524609743222,11113728715403340456,131072 --disable-features=CookiesWithoutSameSiteMustBeSecure,SameSiteByDefaultCookies,SpareRendererForSitePerProcess --lang=fr --app-path=/snap/signal-desktop/370/opt/Signal/resources/app.asar --no-sandbox --no-zygote --num-raster-threads=2 --enable-main-frame-before-activation --renderer-client-id=5 --no-v8-untrusted-code-mitigations --shared-files=v8_context_snapshot_data:100
I don't understand why signal needs that many processes.
wohltat
commented
3 years ago @chmike i also have 9 processes with different types:
More on zygote here Maybe that helps a bit to understand why are there so many. But i dont know what the zygote processes are doing.
wohltat
commented
3 years ago @chmike also on my machine its the renderer process and and less the gpu process that is using most cpu time.
I guess this is the place for potential improvement since there should not be too much to render with a minimized app.
nickma82
commented
3 years ago Maybe related to #5127
wohltat
commented
3 years ago What we need is more information from you - we need you to be scientists.
scientific enough?
sgebbie
commented
2 years ago I have regularly experienced a similar problem with signal-desktop. It ends up being a battery drain on a laptop, which is unfortunate.
Taking a look at strace didn't reveal much activity, other than timers. Which, for what it is work, implies that the behaviour is more user-land based:
Snippet from top show >20% CPU usage while signal-desktop should be idle:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
198281 stewart 20 0 36.9g 246472 128616 S 21.1 1.5 18:00.13 signal-desktop The corresponding output from strace didn't show much:
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=634689719}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=635234725}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=635743355}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=636054817}) = 0
gettimeofday({tv_sec=1635778054, tv_usec=201906}, {tz_minuteswest=0, tz_dsttime=0}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=636607698}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=636883577}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=637139954}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=637354790}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381412, tv_nsec=637568043}) = 0
futex(0x7ffd59efde58, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=381413, tv_nsec=632863043}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=633711139}) = 0
futex(0x7ffd59efde08, FUTEX_WAKE_PRIVATE, 1) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=634445438}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=634690900}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=634932361}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=635216197}) = 0
gettimeofday({tv_sec=1635778055, tv_usec=201056}, {tz_minuteswest=0, tz_dsttime=0}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=635757912}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=636016498}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=636199541}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=636369918}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381413, tv_nsec=636550587}) = 0
futex(0x7ffd59efde58, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=381414, tv_nsec=632758587}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=633430212}) = 0
futex(0x7ffd59efde08, FUTEX_WAKE_PRIVATE, 1) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=633972635}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=634198929}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=634432015}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=634596308}) = 0
gettimeofday({tv_sec=1635778056, tv_usec=200378}, {tz_minuteswest=0, tz_dsttime=0}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=635017188}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=635250357}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=635566486}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=635816780}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381414, tv_nsec=636149951}) = 0
futex(0x7ffd59efde58, FUTEX_WAIT_BITSET_PRIVATE, 0, {tv_sec=381415, tv_nsec=632870951}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
clock_gettime(CLOCK_MONOTONIC, {tv_sec=381415, tv_nsec=633408268}) = 0
futex(0x7ffd59efde08, FUTEX_WAKE_PRIVATE, 1) = 0With the above pattern repeating.
Skimming back up through the posts on this issue, the above seems to correlate with the findings with ltrace mentioned in: https://github.com/signalapp/Signal-Desktop/issues/5444#issuecomment-903029913, in terms of calls to clock_gettime. But, again, the rate of calls is not unreasonable and would not account for the high CPU loss or indicate a tightly loop that should be polling etc.
But, it would be nice to get to the bottom of this as it does detract from the day-to-day usage of, an otherwise, good application.
EvanHahn-Signal
commented
2 years ago @sgebbie Thanks for this investigation. We're still stumped, but this is helpful.
sgebbie
commented
2 years ago As another experiment, if another user starts typing the signal-desktop shows the "typing" ellipses....
Whenever this happens, I can correlate this with an increase in CPU usage from the reasonable idle state of 1% up to ~5% (and once up to 6%). But, once the ellipse animation stops, the CPU usage also falls back down to a more reasonable 1%.
But this does not trigger the long running higher CPU usage.
kaimast
commented
2 years ago Maybe close this issue in favor of #4459 ?
felix-engelmann
commented
2 years ago @kaimast after reading #4459 it looks like a different issue. Their issue is resolvable by not showing animations or minimizing the window. However this issue here persists even when no chat is selected, nothing is animation and the window is minimized. It does not seem to be related to the visualization.
dodiak
commented
2 years ago Same problem here. All the time about 20-22% of one core of my Debian running on i7-7600U CPU @ 2.80GHz
alien2003
commented
2 years ago Reproduced on Arch Linux both on Desktop and mobile while just setting in tray and doing nothing. Both Beta and release affected
kaimast
commented
2 years ago Do you still see this with ozone enabled? --enable-features=UseOzonePlatform
I am on Arch as well and only see occasional spikes from 0% to 2% (like once a minute), when, I assume, it is checking for messages.
alien2003
commented
2 years ago Do you still see this with ozone enabled?
--enable-features=UseOzonePlatformI am on Arch as well and only see occasional spikes from 0% to 2% (like once a minute), when, I assume, it is checking for messages.
The same with Ozone. It was 0% usage, I opened a chat with friend and minimized window to tray, now it just drains 7-8% doing nothing, not even rendering the window
UPD: 14-15% CPU now, doing nothing in background while sitting in tray. Electron is being electron
UPD: 54% in the morning after all the night just idling and doing nothing. That's ridiculous
alien2003
commented
2 years ago Opening Signal window, selecting random chat, pressing Ctrl-Shift-C and minimazing Signal again helps, at least when Signal drains 7-8% CPU, it camls down after it. Not for a long time, for 1-2 minutes, after that, it starts doing electron things again
xadhatter
commented
2 years ago I am seeing the same issue. CPU usage ~10% when Signal is idle, more when in use. It creates a noticeable battery drain, to the point I now exit Signal when on battery. Please let me know if there is any additional information that would be helpful to diagnose.
Signal 5.26.1 Fedora Linux 35 Cinnamon 5.0.7 Kernel 5.15 AMD Ryzen 5 PRO 5650U
chronos000
commented
2 years ago check out possible solution on this comment: https://github.com/signalapp/Signal-Desktop/issues/4459#issuecomment-1003053281
TL;DR: disable notifications in Signal's setting
otherwiseguy
commented
2 years ago I would be ecstatic to have ~10% CPU when idle. For me, it's currnetly like this:
1754222 twilson 20 0 26.3g 515540 249380 S 51.8 0.8 3360:43 signal-desktop
and I've seen it hover in the 70s when idle.
nagisa
commented
2 years ago I can reproduce this immediately after launch as well.
--type=renderer process.So it looks like having signal with a chat contents showing is at least one of the causes here.
I'm using sway as my compositor and signal is placed on an workspace from which I've switch away. I have tried both --enable-features=UseOzonePlatform --ozone-platform=x11 and --enable-features=UseOzonePlatform --ozone-platform=wayland – both behave the same.
I've disabled the notifications as suggested two comments above – no difference.
The built-in chrome profiler reveals no interesting information, it shows ~12ms of busy time in a range of 10 seconds, clearly contradicting the system-wide metrics.
The following profile I did with perf for the offending --type=renderer process does look pretty interesting, though. Here I ran signal with a chat selected for ~30 seconds (high idle cpu use), and then deselected it (low idle cpu usage.) From the looks of it, mallinfo/node::GetEnvironmentIsolateData functions end up being called with significant frequency from the Compositor thread.
Does that help to narrow down the reason in any way?
VadimMuhtarov
commented
2 years ago I have the same problem. Idle wake-ups with closed window is almost equal to Skype wake-ups during video call.
Bug Description
signal-desktop is constantly using around minimum 4% CPU on my computer even it is in the background and nothing is happening.
Steps to Reproduce
i just start signal-desktop via command line
signal-desktopand minimize it.Actual Result: 4%-10% or more CPU usage in idle state. This around as much or more than my window manager uses.
Expected Result: 1% or less CPU usage.
Platform Info
Signal Version: v5.7.1
Operating System: No LSB modules are available. Distributor ID: Linuxmint Description: Linux Mint 20.1 Release: 20.1 Codename: ulyssa
Linux 5.4.0-80-generic #90-Ubuntu SMP Fri Jul 9 22:49:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Linked Device Version: Android Version: 6.0.1
strace, ltrace
profiling for 10seconds of app running
Most time is spend in library calls and not in syscalls. I still don't really know how to interpret this since with 4% CPU usage over 10s should be something like 0.4 seconds.