text:
CPU use on both Linux and Windows clients

I confirm (by marking "x" in the [ ] below: [x]):

[x] This is not a troubleshooting question. Troubleshooting questions go here: http://www.mattermost.org/troubleshoot/.
[ ] This doesn't reproduce on web browsers (such as in Chrome). Though I didn't try for days or months as I did with Mattermost Desktop [Edited to uncheck this since @hunterlester has suggested the issue might be on the webapp side, and I did not test thoroughly. If confirmed, it would explain why the issues affect all platforms.
[x] I have read contributing guidelines.

Summary
The CPU use of the Mattermost desktop client seems way higher than it should on Linux and Windows (also reported on Mac in #222, and Windows and Linux in the said issue by myself with screenshots). Another example:

The screenshot was taken just after starting Mattermost, but the same statistics can persist hours later.
I have been having this issue with the Mattermost Linux client version 4.1.2 as well as previous versions in the past, and so did one of my users who uses the Windows client. I have posted in #222 to give details on our observations on both platforms.
However, issue #222 seems to be specific to Mac and has been related to animated gifs on that case, so it may be a different problem. There are several other issues on CPU use here, but most have been closed due to inactivity rather than real solutions. Therefore, I believe it is better to open another issue to show that the problem happens on other platforms than Mac,  regardless of animated gifs and HTML previews.
Environment

Operating Systems: Solus 4.0 (myself) and Windows 10 (a user)
Mattermost Desktop App version: 4.1.2 and unknown for Windows 10, but about the same period and past versions over the last two years (not all versions have been tested though)
Mattermost Server version: 5.7.0

Steps to reproduce
Hard to tell: Mattermost does not always show high CPU use like on the screenshot above, but it is fairly common (several times a week) and will last even after restarting the application. I failed to identify anything in the conversations that correlates with the CPU use. Not sure what stops it either. I initially thought it would be animated gifs or HTML previews after reading #222, but I observed that there was no relation.
Expected behavior
Lower CPU use.
Observed behavior
Sometimes, all the CPU resources available are used.

I'm observing the same behavior on Fedora 29.
Attached a screenshot as well.
Desktop client version is 4.2.1
Happens across all server versions.

Ticket for reference: https://mattermost.atlassian.net/browse/MM-16626.

This is still happening with 4.2.1 on Windows and 4.2.3 on Linux.

Confirmed, Linux 4.2.3 constantly hogs ~4% of CPU and making laptop fans spin, which means something incorrect inside Mattermost is running in a constant polling loop of some kind.
Feels like a regression from 4.2.0, because I'm monitoring for this type of stuff pretty actively, and don't think I noticed that earlier.
Slack v4 client seems to have made massive improvement strides with this, as it now seems to be nearly idle when sitting in the background.
Would love to get that kind of performance out of Mattermost client as well.

I'm wondering if this is not an issue at all with the desktop application but rather with the webapp, which should be very encouraging.
I cloned the master branch of desktop and observed upon launch that it will idle nicely at 0.0 CPU usage. I add server web URL: https://chat.redox-os.org. Only upon logging in to server do I see a jump in CPU usage, idling between 6% to 8%.
By comparison, I open a single tab in Chrome, idling at 0.0 CPU usage. I navigate to https://chat.redox-os.org. Upon logging in I see a jump in Google Chrome process, idling between 6% to 8%.
I'm testing on macOS Mojave 10.14.6. I intend to also test on Windows and Linux, when I get a chance...
Next step is to dive into webapp codebase.
In particular I want to measure websocket packets to look at the size and what kind of IO work is being performed in them.

@hunterlester I'm currently running webapp in Firefox 69 as daily driver, and it does not show similar CPU hogging symptoms. But I'll continue to keep an eye on this.

@lkraav For the firefox process what is it's rough idling CPU usage when signed into server?
I also see around 6% CPU usage in webapp on Firefox once logged into server, however, interestingly the one difference is that when the Firefox window is hidden, CPU usage does return to 0.0, unlike Chrome.

Thanks for digging in that direction. I also failed to reproduce it with the webapp, but as mentioned in the first post, I did not thoroughly test this. I edited the first message to reflect this.
Your observation of a 6% CPU use seems quite good though compared to the more than 60% (or even more than 80% sometimes) in my screenshot (on an i5 7200U CPU).

Quick update, I've just tested in the same manner on Ubuntu 18.04.3.
@Kabouik What is your CPU usage before logging into server and then after logging into server?
So far I observe it consistently increases upon logging in and accessing webapp, whether through Electron or Firefox, or Chrome.
I'll be testing on WIndows as well, hopefully tonight...

Just tested on Windows and observing same behavior as my tests on Linux and macOS.
Of course I'm missing something. Still think it's a server/webapp issue and not specific to this desktop app.
I happen to be logging into https://chat.redox-os.org, which is not a very active server.
My next tests will be while connected to the Mattermost community server.
To help narrow down this issue I'll be logging web socket events as well as packet payloads in the webapp.
I also want to find out if there's any additional data being sent over the server-to-client heartbeat.

Confirmed, my Linux client is definitely a CPU hogger

Nothing visibly exciting going on in the active chat window, just some text and static images pasted.

Update:
Not enough web socket events to account for the consistent CPU usage.
Next is tracing sys calls. I'll need help understanding as this is new ground for me.
System rebooted with csrutil disabled.
Running dtruss -s -ap <Electron PID> for 60 seconds.
Summary sys calls:
CALL                                        COUNT
__disable_threadsignal                          2
bsdthread_create                                2
bsdthread_terminate                             2
getrlimit                                       2
proc_info                                       2
thread_selfid                                   2
mprotect                                        7
madvise                                        38
psynch_mutexdrop                              105
psynch_mutexwait                              105
ulock_wait                                    158
ulock_wake                                    158
psynch_cvsignal                              2439
psynch_cvwait                                2441
read                                         3313
recvmsg                                      7701
write                                       15842
kevent                                      33923

Will read about kevent, to find out what effect it has on CPU.
The write events I would think are significant.
Simultaneously running iosnoop -p <Electron ID> but did not see IO activity corresponding to the number of read and write sys calls.
I only observed 11 IO events performed by Electron.
I wonder if it’s because the IO events are coming from the web app, which is a sandboxed environment and must not directly write or read from files but indirectly through memory.
Example write thread stack:
 1768/0x212e:   8631296      28     26 write(0x19, "\030\0", 0x28C8)		 = 8192 0

              libsystem_kernel.dylib`write+0xa
              Electron Framework`0x0000000104830a00+0x40f
              Electron Framework`0x0000000104830450+0xc7
              Electron Framework`0x0000000104830220+0x2c
              Electron Framework`0x0000000105aecd20+0xd6
              Electron Framework`0x0000000105af7220+0x4ac
              Electron Framework`0x0000000105aecf50+0x7f
              Electron Framework`0x0000000105a6b550+0x1a8
              Electron Framework`0x0000000105ab0640+0x1aa
              Electron Framework`0x0000000105aed410+0x57
              libsystem_pthread.dylib`_pthread_body+0x7e
              libsystem_pthread.dylib`_pthread_start+0x42
              libsystem_pthread.dylib`thread_start+0xd
```

***

By comparison, a single tab open in Firefox, accessing same Mattermost server, running `dtruss -s -ap <Firfox PID>`, also for 60 seconds.

Note: CPU usage between Firefox process and Electron process was comparable.

```

CALL                                        COUNT
fsync                                           1
getegid                                         1
geteuid                                         1
getgid                                          1
getsockname                                     1
getsockopt                                      1
kqueue                                          1
mkdir                                           1
unlink                                          1
ftruncate                                       2
rename                                          2
sendmsg_nocancel                                2
socketpair                                      2
sysctl                                          2
__disable_threadsignal                          3
bsdthread_create                                3
bsdthread_terminate                             3
getpeername                                     4
statfs64                                        4
close_nocancel                                  5
lseek                                           6
shm_open                                        6
connect                                         7
fstat64                                         7
socket                                          7
munmap                                          8
psynch_cvclrprepost                             8
sendto_nocancel                                 8
access                                         10
proc_info                                      10
select_nocancel                                10
getattrlist                                    11
getuid                                         11
kevent_qos                                     12
necp_client_action                             12
thread_selfid                                  12
gettimeofday                                   13
poll                                           13
madvise                                        16
recvfrom_nocancel                              22
open                                           27
pread                                          28
setsockopt                                     30
mprotect                                       32
close                                          42
sendto                                         42
select                                         47
psynch_mutexdrop                               51
psynch_mutexwait                               52
fcntl                                          65
stat64                                         67
mmap                                           71
recvfrom                                      150
kevent_id                                    1289
workq_kernreturn                             1313
recvmsg                                      2469
psynch_cvsignal                              3868
sendmsg                                      4926
read                                         4948
write                                        4956
psynch_cvbroad                               6074
kevent                                       6155
psynch_cvwait                               19797

Next steps are to research sys calls to understand effect on CPU.
Which files are being written to and what is being written.
iosnoop doesn't give me insight, so need to dig into Dtrace toolbox

Next step is to look up those Electron Framework'0x... addresses, with the goal of determining the functions which are being called, resulting in continuous write and kevent syscalls, which appear to be correlated with consistent CPU usage.
Logging thread stacks using dtrace -p <Electron Helper PID> -n 'syscall::write:entry {ustack()}'. Also looking at syscall::kevent:entry`.
Note: It's not my intention to spam this thread. I'm documenting the process so that more experienced engineers can point out gaps in my knowledge and secondly for others to be able to learn.
Thinking that ustack isn't able to resolve Electron Framework function symbol names as those may be defined and allocated at runtime. Given that Electron(Chromium) is based on V8, perhaps those functions don't exist at the time of process creation, so they won't be a part of the process's symbol table. So those addresses may be referencing runtime, heap allocated functions.
Think it's confirmed when taking core dump of the process and bt all in lldb:
    frame #0: 0x00007fff68bed78e libsystem_kernel.dylib`kevent + 10
    frame #1: 0x000000010e7fa969 Electron Framework`___lldb_unnamed_symbol124545$$Electron Framework + 89
    frame #2: 0x000000010e7f845d Electron Framework`___lldb_unnamed_symbol124506$$Electron Framework + 573
    frame #3: 0x000000010e7ee117 Electron Framework`___lldb_unnamed_symbol124239$$Electron Framework + 455
    frame #4: 0x000000010e76c6f8 Electron Framework`___lldb_unnamed_symbol122108$$Electron Framework + 424
    frame #5: 0x000000010e7b17ea Electron Framework`___lldb_unnamed_symbol123124$$Electron Framework + 426
    frame #6: 0x000000010e7ee467 Electron Framework`___lldb_unnamed_symbol124250$$Electron Framework + 87
    frame #7: 0x00007fff68ca62eb libsystem_pthread.dylib`_pthread_body + 126
    frame #8: 0x00007fff68ca9249 libsystem_pthread.dylib`_pthread_start + 66
    frame #9: 0x00007fff68ca540d libsystem_pthread.dylib`thread_start + 13

Or using lldb, nothing returns when running `image lookup --address .
How do I lookup symbol names for dynamically allocated functions?
Thinking that I need to obtain a V8 heap dump then figure out how to resolve the core dump memory addresses.

Hi,
I have the same issue : the desktop app eats 15% of my i7 CPU doing nothing.
It happens ONLY when the main window is opened and decreases to 1% when closed but with the notification icon in the taskbar (app running).
As I have no change enabling GPU acceleration or not, I just suspect a bug with the display.

I've been using the MM web client in Firefox for the past few months to work around this issue.

I'm running on a Pi3 and in normal use is absolutely fine.  However - as soon as I attempt to upload a jpg image > 1mb all 4 cores peg at 100% and the interface shows "processing". Tried by web and windows client so far. Smaller images are fine.

4.4.0-rc1 still continously hogs 6% CPU. Kills battery life, so AC-only.

@lkraav @artfulrobot Hi all, I'm not certain but I may have found one of the performance issues, however I can't rely on my own measurements.
Really curious to know if you see any difference in these artifacts: https://circleci.com/gh/mattermost/desktop/5442#artifacts/containers/0
Base on this PR, in case you want to verify what you're installing.

Something else I want to confirm is what percentage of CPU usage the web app accounts for.
What is the extra CPU usage in your Chrome/Firefox/etc process(es) when running MM?
That's an important comparison that's consistently missing in our measurements.

Really curious to know if you see any difference in these artifacts: https://circleci.com/gh/mattermost/desktop/5442#artifacts/containers/0

Unfortunately there doesn't seem to be a difference.

Something else I want to confirm is what percentage of CPU usage the web app accounts for.
What is the extra CPU usage in your Chrome/Firefox/etc process(es) when running MM?

My observation has always been that webapp doesn't suffer from this cycle churn. Firefox has about:performance monitor available, MM tab most of the time sits completely idle. Perhaps there are more in-depth in-browser cycle monitoring tools available, not sure what they are, for now.

@lkraav Thank you for taking the time. I really appreciate it.
I'm also noticing next to no CPU usage in Electron dev console CPU profiler.
So, my next line of investigation is through V8 profiler.
Passing --js-flags="--prof" when executing electron to generate isolate CPU tick log files. Then processing with node --prof-process`.
Hopefully leads to good clues:
   ticks  total  nonlib   name
      1    0.0%    0.1%  JavaScript
    685    9.1%   99.4%  C++
     14    0.2%    2.0%  GC
   6856   90.9%          Shared libraries
      3    0.0%          Unaccounte

where most of CPU time is taken by /usr/lib/system/libsystem_kernel.dylib
Leaving a trail so that a bunch of us can investigate.

Nice, thanks for instructions
$ [-] node --prof-process isolate-0x*.log
Testing v8 version different from logging version
Code move event for unknown code: 0x3b3fad641258
Code move event for unknown code: 0x3b3fad6414b8
Code move event for unknown code: 0x134eae080138
Code move event for unknown code: 0x21b2a6f064f8
Code move event for unknown code: 0x21b2a6f07100
Code move event for unknown code: 0x21b2a6f075e0
Code move event for unknown code: 0x21b2a6f07918
Code move event for unknown code: 0x21b2a6f07ae8
Code move event for unknown code: 0x21b2a6f08068
Code move event for unknown code: 0x21b2a6f08478
Code move event for unknown code: 0x134eae082ad8
Code move event for unknown code: 0x21b2a6f09698
Code move event for unknown code: 0x134eae083100
Code move event for unknown code: 0x21b2a6f09800
Code move event for unknown code: 0x134eae083340
Code move event for unknown code: 0x3b3fad64f5c8
Code move event for unknown code: 0x21b2a6f09a18
Code move event for unknown code: 0x21b2a6f09bb0
Code move event for unknown code: 0x22436d38aa78
Code move event for unknown code: 0x3b3fad64fa20
Code move event for unknown code: 0x134eae083778
Code move event for unknown code: 0x3b3fad650190
Code move event for unknown code: 0x22436d38cbb0
Code move event for unknown code: 0x3b3fad650e00
Code move event for unknown code: 0x134eae083c00
Code move event for unknown code: 0x134eae083e58
Code move event for unknown code: 0x134eae084248
Code move event for unknown code: 0x134eae0843b0
Code move event for unknown code: 0x134eae0847b8
Code move event for unknown code: 0x134eae084ae8
Code move event for unknown code: 0x134eae085010
Code move event for unknown code: 0x134eae085d00
Code move event for unknown code: 0x134eae086490
Code move event for unknown code: 0x134eae086690
Code move event for unknown code: 0x134eae0869d0
Code move event for unknown code: 0x134eae086d50
Code move event for unknown code: 0x134eae086ee8
Code move event for unknown code: 0x134eae087070
Code move event for unknown code: 0x134eae087190
Code move event for unknown code: 0x134eae087248
Code move event for unknown code: 0x134eae087498
Code move event for unknown code: 0x134eae087750
Code move event for unknown code: 0x134eae087978
Code move event for unknown code: 0x134eae087cf8
Code move event for unknown code: 0x134eae0880a8
Code move event for unknown code: 0x134eae088248
Code move event for unknown code: 0x134eae088420
Code move event for unknown code: 0x134eae088708
Code move event for unknown code: 0x134eae088af0
Code move event for unknown code: 0x22436d394de8
Code move event for unknown code: 0x134eae088e20
Code move event for unknown code: 0x134eae089050
Code move event for unknown code: 0x134eae089130
Code move event for unknown code: 0x3b3fad6635d0
Code move event for unknown code: 0x22436d398450
Code move event for unknown code: 0x22436d3987f8
Code move event for unknown code: 0x3b3fad663768
Code move event for unknown code: 0x134eae089460
Code move event for unknown code: 0x134eae089658
Code move event for unknown code: 0x22436d398d00
Code move event for unknown code: 0x3b3fad6644a0
Code move event for unknown code: 0x134eae089760
Code move event for unknown code: 0x22436d399778
Code move event for unknown code: 0x134eae089920
Code move event for unknown code: 0x134eae089a28
Code move event for unknown code: 0x22436d399ec0
Code move event for unknown code: 0x134eae089cf8
Code move event for unknown code: 0x3b3fad66a260
Code move event for unknown code: 0x22436d39de68
Code move event for unknown code: 0x134eae089fd8
Code move event for unknown code: 0x3b3fad66e530
Code move event for unknown code: 0x22436d3a1be0
Code move event for unknown code: 0x22436d3a1e18
Code move event for unknown code: 0x3b3fad66eef8
Code move event for unknown code: 0x134eae08a198
Code move event for unknown code: 0x22436d3a2100
Code move event for unknown code: 0x22436d3a2328
Code move event for unknown code: 0x22436d3a4120
Code move event for unknown code: 0x134eae08a3d0
Code move event for unknown code: 0x3b3fad66f0c0
Code move event for unknown code: 0x3b3fad66f268
Code move event for unknown code: 0x22436d3a5888
Code move event for unknown code: 0x21b2a6f375b8
Code move event for unknown code: 0x21b2a6f38760
Code move event for unknown code: 0x134eae08a9c8
Code move event for unknown code: 0x22436d3aaf38
Code move event for unknown code: 0x22436d3ab390
Code move event for unknown code: 0x22436d3ab728
Code move event for unknown code: 0x22436d3abb30
Code move event for unknown code: 0x22436d3aca08
Code move event for unknown code: 0x134eae08b1d8
Code move event for unknown code: 0x21b2a6f3b828
Code move event for unknown code: 0x22436d3ad180
Code move event for unknown code: 0x3b3fad673798
Code move event for unknown code: 0x134eae08b5e8
Code move event for unknown code: 0x134eae08b6e0
Code move event for unknown code: 0x21b2a6f3c2f0
Code move event for unknown code: 0x3b3fad673ea0
Code move event for unknown code: 0x22436d3ad618
Code move event for unknown code: 0x134eae08b888
Code move event for unknown code: 0x134eae08b950
Code move event for unknown code: 0x134eae08ba28
Code move event for unknown code: 0x3b3fad6751b0
Code move event for unknown code: 0x21b2a6f3c4f8
Code move event for unknown code: 0x22436d3add78
Code move event for unknown code: 0x134eae08bc40
Code move event for unknown code: 0x3b3fad675588
Code move event for unknown code: 0x21b2a6f3c940
Code move event for unknown code: 0x22436d3ae200
Code move event for unknown code: 0x134eae08bde0
Code move event for unknown code: 0x3b3fad676070
Code move event for unknown code: 0x21b2a6f3cb08
Code move event for unknown code: 0x134eae08c2e0
Code move event for unknown code: 0x22436d3ae8a0
Code move event for unknown code: 0x22436d3aea18
Code move event for unknown code: 0x22436d3b0f68
Code move event for unknown code: 0x134eae08d068
Code move event for unknown code: 0x22436d3b1548
Code move event for unknown code: 0x134eae08d670
Code move event for unknown code: 0x22436d3b1bb8
Code move event for unknown code: 0x22436d3b1d58
Code move event for unknown code: 0x3b3fad67b140
Code move event for unknown code: 0x134eae08da70
Code move event for unknown code: 0x22436d3b2190
Code move event for unknown code: 0x22436d3b2400
Code move event for unknown code: 0x22436d3b2548
Code move event for unknown code: 0x134eae08e928
Code move event for unknown code: 0x22436d3b27e8
Code move event for unknown code: 0x3b3fad67e3b8
Code move event for unknown code: 0x3b3fad67e568
Code move event for unknown code: 0x134eae08edf0
Code move event for unknown code: 0x22436d3b2f38
Code move event for unknown code: 0x134eae08f520
Code move event for unknown code: 0x134eae08f860
Code move event for unknown code: 0x22436d3b5540
Code move event for unknown code: 0x22436d3b60e8
Code move event for unknown code: 0x134eae091868
Code move event for unknown code: 0x22436d3b7bf0
Code move event for unknown code: 0x22436d3b8050
Code move event for unknown code: 0x134eae093428
Code move event for unknown code: 0x22436d3b8490
Code move event for unknown code: 0x22436d3b8620
Code move event for unknown code: 0x134eae093848
Code move event for unknown code: 0x134eae093990
Code move event for unknown code: 0x134eae093a48
Code move event for unknown code: 0x134eae093b00
Code move event for unknown code: 0x134eae093bb8
Code move event for unknown code: 0x22436d3b8c40
Code move event for unknown code: 0x22436d3b8eb8
Code move event for unknown code: 0x134eae0950a8
Code move event for unknown code: 0x134eae0970c0
Code move event for unknown code: 0x22436d3b9d58
Code move event for unknown code: 0x134eae097d28
Code move event for unknown code: 0x22436d3bae80
Code move event for unknown code: 0x22436d3bb698
Code move event for unknown code: 0x134eae098198
Code move event for unknown code: 0x134eae0983b8
Code move event for unknown code: 0x134eae0985a8
Code move event for unknown code: 0x22436d3bba20
Code move event for unknown code: 0x134eae0990c8
Code move event for unknown code: 0x22436d3bc8a0
Code move event for unknown code: 0x22436d3bcc28
Code move event for unknown code: 0x134eae09af78
Code move event for unknown code: 0x134eae09b600
Code move event for unknown code: 0x22436d3bd5e0
Code move event for unknown code: 0x134eae09d588
Code move event for unknown code: 0x134eae09d710
Code move event for unknown code: 0x22436d3bd9f0
Code move event for unknown code: 0x22436d3bde10
Code move event for unknown code: 0x134eae09e940
Code move event for unknown code: 0x22436d3be518
Code move event for unknown code: 0x134eae09ec60
Code move event for unknown code: 0x134eae09eff0
Code move event for unknown code: 0x22436d3be818
Code move event for unknown code: 0x134eae09fcd8
Code move event for unknown code: 0x22436d3befe8
Code move event for unknown code: 0x22436d3bf600
Code move event for unknown code: 0x134eae0a1508
Code move event for unknown code: 0x134eae0b8370
Statistical profiling result from isolate-0xcfd640ff000-1732473-v8.log, (27485 ticks, 0 unaccounted, 0 excluded).

 [Shared libraries]:
   ticks  total  nonlib   name
    285    1.0%          /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      8    0.0%          /usr/lib64/libc-2.29.so
      5    0.0%          /usr/lib64/ld-2.29.so
      2    0.0%          /usr/lib64/libgdk-3.so.0.2404.7
      2    0.0%          /usr/lib64/libexpat.so.1.6.10
      1    0.0%          /usr/lib64/libxcb.so.1.1.0
      1    0.0%          /usr/lib64/libgtk-3.so.0.2404.7
      1    0.0%          /usr/lib64/libglib-2.0.so.0.6000.7
      1    0.0%          /usr/lib64/libfreetype.so.6.16.1
      1    0.0%          /usr/lib64/libdbus-1.so.3.19.11

 [JavaScript]:
   ticks  total  nonlib   name
      1    0.0%    0.0%  LazyCompile: *normalizeString path.js:52:25

 [C++]:
   ticks  total  nonlib   name
  27052   98.4%   99.5%  __poll
     46    0.2%    0.2%  __pthread_cond_wait
     13    0.0%    0.0%  __write
     11    0.0%    0.0%  __libc_recvmsg
      6    0.0%    0.0%  __lll_lock_wait
      4    0.0%    0.0%  __GI___pthread_timedjoin_ex
      2    0.0%    0.0%  v8::internal::Scanner::Next()
      2    0.0%    0.0%  v8::internal::JSObject::MigrateToMap(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Map>, int)
      2    0.0%    0.0%  g_mutex_lock
      2    0.0%    0.0%  fwrite
      2    0.0%    0.0%  __pthread_cond_signal
      2    0.0%    0.0%  __libc_send
      1    0.0%    0.0%  v8::internal::wasm::WasmCodeRefScope::WasmCodeRefScope()
      1    0.0%    0.0%  v8::internal::interpreter::BytecodeArrayWriter::Write(v8::internal::interpreter::BytecodeNode*)
      1    0.0%    0.0%  v8::internal::interpreter::BytecodeArrayBuilder::StoreAccumulatorInRegister(v8::internal::interpreter::Register)
      1    0.0%    0.0%  v8::internal::String::SlowEquals(v8::internal::String)
      1    0.0%    0.0%  v8::internal::StackGuard::PopInterruptsScope()
      1    0.0%    0.0%  v8::internal::StackFrameIterator::StackFrameIterator(v8::internal::Isolate*)
      1    0.0%    0.0%  v8::internal::ScannerStream::For(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>, int, int)
      1    0.0%    0.0%  v8::internal::Scanner::PeekAhead()
      1    0.0%    0.0%  v8::internal::Parser::InitializeVariables(v8::internal::ScopedPtrList<v8::internal::Statement>*, v8::internal::VariableKind, v8::internal::ParserBase<v8::internal::Parser>::DeclarationParsingResult::Declaration const*)
      1    0.0%    0.0%  v8::internal::Parser::DoParseFunction(v8::internal::Isolate*, v8::internal::ParseInfo*, v8::internal::AstRawString const*)
      1    0.0%    0.0%  v8::internal::LookupIterator::PrepareTransitionToDataProperty(v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::StoreOrigin)
      1    0.0%    0.0%  v8::internal::FeedbackNexus::ExtractMaps(std::__1::vector<v8::internal::Handle<v8::internal::Map>, std::__1::allocator<v8::internal::Handle<v8::internal::Map> > >*) const
      1    0.0%    0.0%  v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::RootIndex, int, v8::internal::Object, v8::internal::AllocationType)
      1    0.0%    0.0%  v8::internal::Factory::CopyJSObjectWithAllocationSite(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::AllocationSite>)
      1    0.0%    0.0%  v8::internal::DeclarationScope::Analyze(v8::internal::ParseInfo*)
      1    0.0%    0.0%  v8::internal::AccountingAllocator::~AccountingAllocator()
      1    0.0%    0.0%  v8::WasmModuleObjectBuilderStreaming::OnBytesReceived(unsigned char const*, unsigned long)
      1    0.0%    0.0%  v8::MicrotasksScope::PerformCheckpoint(v8::Isolate*)
      1    0.0%    0.0%  syscall
      1    0.0%    0.0%  gdk_keymap_get_entries_for_keycode
      1    0.0%    0.0%  g_hash_table_lookup
      1    0.0%    0.0%  g_bit_unlock
      1    0.0%    0.0%  do_futex_wait.constprop.1
      1    0.0%    0.0%  access
      1    0.0%    0.0%  __pthread_cond_timedwait
      1    0.0%    0.0%  __libc_read
      1    0.0%    0.0%  __libc_open
      1    0.0%    0.0%  __clone
      1    0.0%    0.0%  __clock_gettime
      1    0.0%    0.0%  __GI___pthread_mutex_lock
      1    0.0%    0.0%  _IO_setb
      1    0.0%    0.0%  _IO_file_sync
      1    0.0%    0.0%  XextFindDisplay

 [Summary]:
   ticks  total  nonlib   name
      1    0.0%    0.0%  JavaScript
  27177   98.9%  100.0%  C++
     19    0.1%    0.1%  GC
    307    1.1%          Shared libraries

 [C++ entry points]:
   ticks    cpp   total   name
      6   23.1%    0.0%  __write
      2    7.7%    0.0%  v8::internal::Scanner::Next()
      2    7.7%    0.0%  v8::internal::JSObject::MigrateToMap(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Map>, int)
      1    3.8%    0.0%  v8::internal::wasm::WasmCodeRefScope::WasmCodeRefScope()
      1    3.8%    0.0%  v8::internal::interpreter::BytecodeArrayWriter::Write(v8::internal::interpreter::BytecodeNode*)
      1    3.8%    0.0%  v8::internal::interpreter::BytecodeArrayBuilder::StoreAccumulatorInRegister(v8::internal::interpreter::Register)
      1    3.8%    0.0%  v8::internal::StackGuard::PopInterruptsScope()
      1    3.8%    0.0%  v8::internal::StackFrameIterator::StackFrameIterator(v8::internal::Isolate*)
      1    3.8%    0.0%  v8::internal::ScannerStream::For(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>, int, int)
      1    3.8%    0.0%  v8::internal::Scanner::PeekAhead()
      1    3.8%    0.0%  v8::internal::Parser::InitializeVariables(v8::internal::ScopedPtrList<v8::internal::Statement>*, v8::internal::VariableKind, v8::internal::ParserBase<v8::internal::Parser>::DeclarationParsingResult::Declaration const*)
      1    3.8%    0.0%  v8::internal::Parser::DoParseFunction(v8::internal::Isolate*, v8::internal::ParseInfo*, v8::internal::AstRawString const*)
      1    3.8%    0.0%  v8::internal::FeedbackNexus::ExtractMaps(std::__1::vector<v8::internal::Handle<v8::internal::Map>, std::__1::allocator<v8::internal::Handle<v8::internal::Map> > >*) const
      1    3.8%    0.0%  v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::RootIndex, int, v8::internal::Object, v8::internal::AllocationType)
      1    3.8%    0.0%  v8::internal::Factory::CopyJSObjectWithAllocationSite(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::AllocationSite>)
      1    3.8%    0.0%  v8::internal::DeclarationScope::Analyze(v8::internal::ParseInfo*)
      1    3.8%    0.0%  fwrite
      1    3.8%    0.0%  __GI___pthread_mutex_lock
      1    3.8%    0.0%  _IO_file_sync

 [Bottom up (heavy) profile]:
  Note: percentage shows a share of a particular caller in the total
  amount of its parent calls.
  Callers occupying less than 1.0% are not shown.

   ticks parent  name
  27052   98.4%  __poll

    285    1.0%  /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
    199   69.8%    /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
     41   20.6%      Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:89:16
     41  100.0%        LazyCompile: ~__webpack_require__ /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:6:39
     41  100.0%          Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:1:19
     41  100.0%            Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:1:1
     27   13.6%      LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
     25   92.6%        LazyCompile: ~nativeModuleRequire internal/bootstrap/loaders.js:185:29
      3   12.0%          Eval: ~<anonymous> internal/bootstrap/node.js:1:1
      3   12.0%          Eval: ~<anonymous> crypto.js:1:1
      3  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      2    8.0%          Eval: ~<anonymous> tls.js:1:1
      2  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      2    8.0%          Eval: ~<anonymous> stream.js:1:1
      2  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      2    8.0%          Eval: ~<anonymous> https.js:1:1
      2  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          LazyCompile: ~initializeCJSLoader internal/bootstrap/pre_execution.js:343:29
      1  100.0%            LazyCompile: ~prepareMainThreadExecution internal/bootstrap/pre_execution.js:8:36
      1    4.0%          LazyCompile: ~get fs.js:1886:8
      1  100.0%            LazyCompile: ~exports.wrapFsWithAsar electron/js2c/asar.js:217:28
      1    4.0%          Eval: ~<anonymous> timers.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          Eval: ~<anonymous> net.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          Eval: ~<anonymous> internal/url.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          Eval: ~<anonymous> internal/modules/cjs/loader.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          Eval: ~<anonymous> internal/console/global.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          Eval: ~<anonymous> fs.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          Eval: ~<anonymous> events.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          Eval: ~<anonymous> electron/js2c/asar_init.js:1:1
      1  100.0%            /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      1    4.0%          Eval: ~<anonymous> electron/js2c/asar.js:3:11
      1  100.0%            Eval: ~<anonymous> electron/js2c/asar.js:1:1
      1    4.0%          Eval: ~<anonymous> child_process.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    4.0%          Eval: ~<anonymous> buffer.js:1:1
      1  100.0%            LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1    3.7%        Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:6745:16
      1  100.0%          LazyCompile: ~__webpack_require__ /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:6:39
      1  100.0%            Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:6677:16
      1    3.7%        Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:28355:16
      1  100.0%          LazyCompile: ~__webpack_require__ /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:6:39
      1  100.0%            Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:28316:16
     19    9.5%      LazyCompile: ~set /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/web-contents.js:315:14
     18   94.7%        /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
     18  100.0%          LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:242:33
     18  100.0%            LazyCompile: ~emit events.js:149:44
      1    5.3%        LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:242:33
      1  100.0%          LazyCompile: ~emit events.js:149:44
      1  100.0%            LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/web-contents.js:338:43
     15    7.5%      LazyCompile: ~createMainWindow /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:21593:26
     15  100.0%        LazyCompile: ~initializeAfterAppReady /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:732:33
     15  100.0%          /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      8    4.0%      LazyCompile: ~WebContents._sendInternal /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/web-contents.js:113:48
      8  100.0%        LazyCompile: ~sendToEmbedder /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/guest-view-manager.js:103:28
      5   62.5%          LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/guest-view-manager.js:118:43
      5  100.0%            LazyCompile: ~emit events.js:149:44
      3   37.5%          LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/guest-view-manager.js:110:34
      3  100.0%            LazyCompile: ~emit events.js:149:44
      6    3.0%      LazyCompile: ~attachGuest /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/guest-view-manager.js:142:30
      6  100.0%        LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/guest-view-manager.js:311:68
      6  100.0%          LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/guest-view-manager.js:289:34
      6  100.0%            LazyCompile: ~callHandler /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/ipc-main-internal-utils.js:5:36
      4    2.0%      LazyCompile: ~NavigationController.loadURL /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/navigation-controller.js:57:55
      2   50.0%        LazyCompile: ~loadURL /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/browser-window.js:118:12
      2  100.0%          LazyCompile: ~createMainWindow /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:21593:26
      2  100.0%            LazyCompile: ~initializeAfterAppReady /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:732:33
      2   50.0%        LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/guest-view-manager.js:82:39
      2  100.0%          LazyCompile: ~onceWrapper events.js:284:21
      2  100.0%            LazyCompile: ~emit events.js:149:44
      3    1.5%      LazyCompile: ~internalBinding internal/bootstrap/loaders.js:128:45
      1   33.3%        LazyCompile: ~setupPrepareStackTrace internal/bootstrap/node.js:299:32
      1  100.0%          Eval: ~<anonymous> internal/bootstrap/node.js:1:1
      1   33.3%        Eval: ~<anonymous> internal/util.js:1:1
      1  100.0%          LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1  100.0%            LazyCompile: ~nativeModuleRequire internal/bootstrap/loaders.js:185:29
      1   33.3%        Eval: ~<anonymous> _http_common.js:1:1
      1  100.0%          LazyCompile: ~NativeModule.compile internal/bootstrap/loaders.js:291:42
      1  100.0%            LazyCompile: ~nativeModuleRequire internal/bootstrap/loaders.js:185:29
      3    1.5%      LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:25703:49
      3  100.0%        LazyCompile: ~listOnTimeout internal/timers.js:480:25
      3  100.0%          LazyCompile: ~processTimers internal/timers.js:460:25
      3    1.5%      /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      2   66.7%        /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      1   50.0%          Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:89:16
      1  100.0%            LazyCompile: ~__webpack_require__ /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:6:39
      1   50.0%          /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      1  100.0%            Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:89:16
      1   33.3%        LazyCompile: ~sortItemsInGroup /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/menu-utils.js:86:26
      1  100.0%          /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      1  100.0%            LazyCompile: ~sortMenuItems /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/menu-utils.js:143:23
      2    1.0%      LazyCompile: ~emit events.js:149:44
      1   50.0%        LazyCompile: ~Session._init /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/session.js:18:36
      1  100.0%          /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      1  100.0%            LazyCompile: ~get /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/session.js:9:12
      1   50.0%        /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      1  100.0%          LazyCompile: ~NavigationController.loadURL /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/navigation-controller.js:57:55
      1  100.0%            LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/guest-view-manager.js:82:39
      2    1.0%      LazyCompile: ~MenuItem.overrideReadOnlyProperty /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/menu-item.js:65:56
      2  100.0%        LazyCompile: ~MenuItem /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/menu-item.js:4:27
      2  100.0%          LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/menu.js:166:20
      2  100.0%            /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      2    1.0%      LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/menu.js:153:28
      2  100.0%        /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      2  100.0%          LazyCompile: ~Menu.setApplicationMenu /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/api/menu.js:139:36
      2  100.0%            LazyCompile: ~handleUpdateMenuEvent /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:995:31
      2    1.0%      Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:9892:16
      2  100.0%        LazyCompile: ~__webpack_require__ /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:6:39
      2  100.0%          Eval: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:9511:16
      2  100.0%            LazyCompile: ~__webpack_require__ /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/app.asar/main_bundle.js:6:39
      3    1.1%    LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:37:22
      3  100.0%      /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/mattermost-desktop
      3  100.0%        LazyCompile: ~getObjectMembers /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:27:35
      2   66.7%          LazyCompile: ~getObjectPrototype /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:52:37
      1   50.0%            LazyCompile: ~valueToMeta /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:62:30
      1   50.0%            LazyCompile: ~getObjectPrototype /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:52:37
      1   33.3%          LazyCompile: ~valueToMeta /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:62:30
      1  100.0%            LazyCompile: ~<anonymous> /home/leho/mattermost-desktop-4.3.0-develop-linux-amd64/opt/Mattermost/resources/electron.asar/browser/rpc-server.js:363:62

Thanks for the instructions. There are many isolate log files. How can I tell which might be relevant?

Ah yes, I'm passing --no-logfile-per-isolate as well as --prof to generate single file.
I'm not certain but it seems like the number of isolates isn't insightful and far as Electron processes are concerned.
Doc on isolate class: https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_isolate.html
Without that flag I was receiving 4 isolate log files and they each had similar profile summary.

We noticed that CPU usage is often caused by animated gifs placed in chats.

We noticed that CPU usage is often caused by animated gifs placed in chats.

Correct. This issue is working on a more general problem.

We noticed that CPU usage is often caused by animated gifs placed in chats.
Not only. #222 is dedicated to CPU use caused by animated gifs, but I posted there results showing that there are CPU spikes even with channels containing no gifs, sometimes actually higher than channels with gifs being displayed in the same teams. This was one of the main reasons why I opened this issue: there are additional causes for CPU spikes that are yet to be identified.

This was one of the main reasons why I opened this issue: there are additional causes for (huge) CPU spikes that haven't been identified yet.

CPU spikes vs low but constant CPU churn are also two different issues :thinking:
Title "CPU use" is rather generic for now..

CPU spikes vs low but constant CPU churn are also two different issues

You are correct, bad wording in my previous message. I actually experience both CPU spikes and unusually high base CPU use (and others too, right?).

I also experience constant 13-15% CPU usage by "Mattermost Helper (Renderer)" on macOS (MBP 2019) with the desktop client (4.4.0.5682). An additional 2% is constantly used by "Mattermost Helper (GPU)" while idle, even when the window is closed but the client is still running the CPU usage stays the same, which is quite counter-intuitive.
Deactivating GPU rendering reduces CPU usage by the Renderer process by about 4%.
Interestingly, the web client on Firefox (74.0, 64-bit) makes Firefox's CPU usage jump up by about 20% while the tab is opened. Switching to another tab returns the CPU usage to the average 5-7%, which is normal in my machine.

Hey folks,
thanks for all your reports.
Another very important info for all reports here is the Mattermost server version.
If you don't know how to get it, it's shown in the About Mattermost tab in your account settings (Hamburger Menu next to your username)

A lot of the performance impacts obviously come from the webapp rendering, so having the server version helps us know where to look for. Sometimes there's already been some improvements in newer version so it's also worth looking into upgrading to a newer version (latest ESR/LTS is 5.19 and latest stable quality release is 5.21)

I got very bad CPU use with the client lately so I tried using it in a browser (not my main browser because I want a separate window), I tried Epiphany (webkit). I still get 50% CPU use on an i5 7th generation CPU, so it's not tied to the Electron application.
Server is 5.7.0, I admit I'm a bit late on that. I have no time to upgrade right now but I will report back once it is done in case there is a significant change in CPU use.

Server is 5.7.0, I admit I'm a bit late on that. I have no time to backup and upgrade right now but I will report back once it is done in case there is a significant change in CPU use.

I have upgrade 5.16 -> 5.21 and there's no difference in desktop client CPU usage.
BUT I did discover something else today: CPU churn apparently radically depends on the size of the channel history

CPU churn all but vanished if I switch to a new / empty or a channel with very few messages (20-30+ total)

CPU churn resumed instantly when I switched to regular work traffic level channels, history of hundreds / thousands messages - it could also be something with images, threads, or whatever high volume channels have more of

That is something I investigated some months ago but I cannot confirm, on my end Mattermost can use 60% CPU even when showing a private channel with less than 10 messages in history.

@lkraav Great finding! I see the exact same thing -- a fresh, empty, channel reduces CPU usage to a perfectly acceptable minimum (<1% CPU in my case).

This has been observed on the browser front-end as well. Moderate CPU usage for chats with long history. Very little CPU usage on chats without history. Reproduced using Chrome.

My main Windows user is reporting that the issue arises mainly when images are posted in a channel, and just a few images are enough to get to 30-50% of CPU use. I don't think the link is that obvious in Linux, I often observed very high CPU use in channels with no images visible (but maybe other channels not being displayed, or past history use CPU too?). However, it's worth investigating in that direction because he is positive about the relationship, since he has to kill the Mattermost process every time I post 3 or 4 images.
Of note, there are no CPU issues whatsoever on mobile applications. Android works exactly the same whether images are being previewed or not. I use a third-party SailfishOS application, and no CPU issue either.

Getting the same issue on both Windows (7 pro 64, 7 ultimate 64, 10 home) and Linux (Ubuntu 18, 19, and 20). Mattermost desktop app ( or -snap app) causing 40-70% CPU load when idle, when hidden, when no messages are coming in in any of the channels. Slightly more load during actual activity.

CPU spikes vs low but constant CPU churn are also two different issues thinking
or high constant CPU churn.

My main Windows user is reporting that the issue arises mainly when images are posted in a channel, and just a few images are enough to get to 30-50% of CPU use.

Note that he added that disabling URL preview and extended image preview in Account settings > Display does not help.

@lkraav Great finding! I see the exact same thing -- a fresh, empty, channel reduces CPU usage to a perfectly acceptable minimum (<1% CPU in my case).

Same here, just switching to an empty channel makes Mattermost disappear from top. Mattermost desktop v4.5.0.6629 on macOS 10.15.5.

Hi, I just noticed that the corresponding jira ticket https://mattermost.atlassian.net/browse/MM-16626 was closed. I know this is difficult to trace down and debug, but shouldn't the issue be kept open?

Thanks, re-opened,

It's funny, but I think I found the problem of idle cpu using. It's the CSS animation of the ".loading-screen .loading__content .round" elements. It's a spinner animation with 3 circles at the top of a channel (used for the chat infinity scroll). It is an infinity animation at an invisible area, but browser render it all the time. It's easy to check. After a loading any chat with a big list of messages we see 4-5% of CPU usage for the Render process. But if you remove the element(display:none) or just disable the animation of the .round elements the CPU of the process drops to 0.1-0.3% (be careful - a Developer console can cause CPU usage that can spoil the test). So the best it's to hide the element if we don't need it. I've made small few experiments, but it seems that the animation or the element must be removed (or hidded by display:none) to solve the problem.

I can confirm that setting display: none on the element matching the selector div.loading-screen greatly helps with the CPU usage of the Mattermost 4.5.0.6629 client on macOS.

@Regul777 you deserve an award of some kind :rocket: :partying_face:
I can confirm @frerich experience: CPU use instantly drops to 0.

I'm not sure when 4.6.0 is planned to be released, but if this hotfix was patched up into 4.5.2 asap, I think nature would sincerely appreciate it.

I've created a jira bug after some investigations. I can confirm this behaviour both in desktop and firefox.
Please, be aware that when this change is merged it will require a server upgrade, not a desktop upgrade as it is not related to desktop source code.
Also, once it is merged I'll keep the issue opened, as I'm sure there will be other factors taking up cpu usage

While we're on this subject, I've noticed opening thread pane also increases continous CPU churn on one of the app threads, at least on Linux. It's not as bad as our main CSS animation guest star here, only about 1+% or so, but still - maybe there's something similar going on? Can anyone else confirm this happening?

Hacky fix in the meantime until the proper fix is released: on the server, search for the client/root.html file and remove the three lines
                <div class='round round-1'></div>
                <div class='round round-2'></div>
                <div class='round round-3'></div>

( https://github.com/mattermost/mattermost-webapp/blob/cf5326bf5df6766d2a41cdd5ac718ddda98c6363/root.html#L73-L75 )
and "Clear Cache and reload" on the clients.
It seems to tame the CPU-demand of the mattermost electron app on linux quite a bit (it still spikes to 25% or so from time to time, even if its in the background)

I'm having a similar issue with the Linux client installed from snap (version 4.5.3). However, my CPU load is way higher than in the comments I see above, for me it just eats a whole CPU all the time, no matter whether the window is minimized or not.
I'm not in control of the server, so I have no clue which version they are running or their setup.

Resolved for me with version 5.26.1. I had >20% CPU over background in two processes, as soon as I switched to the tab in Chrome / OpenSuSE.
Thanks!

I'm having a similar issue with the Linux client installed from snap (version 4.5.3). However, my CPU load is way higher than in the comments I see above, for me it just eats a whole CPU all the time, no matter whether the window is minimized or not.

Can you try disabling GPU in the mattermost config and see if that helps?
The snap installer uses a different path and I'm not sure if it's able to access the same libs as a regular application installed through .deb or others.

I'm not in control of the server, so I have no clue which version they are running or their setup.

If you click on the menu there should be an option called 'about mattermost' which will give you this info

UPDATE: interestingly, the very same version of mattermost-desktop installed through the .deb does not have the same issue, showing a cpu usage under 10% most of the time; should I open a separate issue since this looks snap-related?

Any other issue I'd have asked to fill a separate one, but in this case is fine. I prefer to have  'high CPU usage' issues centralized, as this can be caused by multiple factors and might vary between setups. So having a common place to see the different findings and workarounds might be more useful for users.

You should know by  now chrome uses most of RAM
On Sun, Sep 13, 2020, 17:06 Ralf Stephan notifications@github.com wrote:

Resolved for me with version 5.26.1. I had >20% CPU over background in two
processes, as soon as I switched to the tab in Chrome / OpenSuSE.
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mattermost/desktop/issues/997#issuecomment-691683029,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEJSNM6CMQNGOQIPWCFP27LSFTNY3ANCNFSM4H3IR4GQ
.

Resolved for me with version 5.26.1. I had >20% CPU over background in two processes, as soon as I switched to the tab in Chrome / OpenSuSE.

I doesn't see on any difference in 5.26.1. Still 15-20% CPU usage on all platforms due loading_indicator animation. Do we expect any progress with this?

removal of loading indicator was added into 5.27, so you'll need to upgrade to at least that version in order to see the improvement.

Is there anyone still experiencing high CPU usage on the latest Mattermost Desktop App? We've done a fair amount of work to reduce this.

Version 6.0.1 on Ubuntu 20.04 LTS is also good, low CPU usage (very much different from before).

I had high CPU usage as well and after reading all comments and checking application, discovered something:
After installing matter most, there is a green dot blinking on "Town square". Had it for weeks blinking, initially I believed it was part of "Town square" title, as you can add images or little animations to channel titles.
Then I clicked on it, to my surprise it showed a message and then the green dot migrated to other area of mattermost. After going through all green dots, CPU usage was reduced drastically to the point  that disappeared from top applications.
Hope this helps.

I had high CPU usage as well and after reading all comments and checking application, discovered something: After installing matter most, there is a green dot blinking on "Town square". Had it for weeks blinking, initially I believed it was part of "Town square" title, as you can add images or little animations to channel titles. Then I clicked on it, to my surprise it showed a message and then the green dot migrated to other area of mattermost. After going through all green dots, CPU usage was reduced drastically to the point that disappeared from top applications.
Hope this helps.

I clicked on everything, but not on that green dot... lol.
Helped, thanks!

Seems like most people are experiencing better CPU usage with newer versions.
I will close this for now, but feel free to comment/create a new issue if you experience similar issues with newer versions.

Just to comment it.
We are using Mattermost Version: 6.3.8

authors: DanielWeigl Kabouik Regul777 St333p Willyfrog amyblais devinbinnie dharapl eldruin frerich gabrieleiannetti hunterlester jowilkes lig lkraav mikebakke mparuzel nazavode padeken rwst svelle vimmerru vostorga yomguy

repo: mattermost/desktop


text:
Global relay changelog adjustment

Summary
Sales need something to show that we can integrate with Proofpoint so I made a small adjustment to our changelog. I also fixed a small error where I said it wasn't configurable in the UI.

/update-branch

source: gharchive/pull-request

repo: mattermost/docs

license_type: permissive

license_source: github-api


text:
Add styling for homepage and doc pages

Huge thanks to @asaadmahmood for providing the CSS/HTML and to @jasonblais for coordinating it! Looks like a real professional site now :D
Fixes #8 and #6

Looks awesome from my phone!
Noticing some of the links are broken on the plugins page, but that’s not introduced by this PR.
Will review code this weekend when I’m back at a computer.

authors: ccbrown jwilander


text:
Add commit buttons in form instead of on navigation

Summary
When a form defines several submit buttons, we used to put them in the navigation bar. Due to the limited space, this was not a good idea.
The solution was to add the buttons at the end of the form. This is the first iteration towards that. Programming logic is in place, the only missing parts are design tweaks.
Right now if no custom buttons are defined, the submit button will appear in the navigation bar. If custom buttons are defined, they will be at the bottom.
Ticket Link
https://mattermost.atlassian.net/browse/MM-33360
Screenshots

Release Note
None

@enahum Yes, it will.

Building app in separate branch.

authors: larkox mattermod

repo: mattermost/mattermost-mobile


text:
Cherry-picking translations

Summary
Cherry-picking translations from https://github.com/mattermost/mattermost-mobile/pull/7859
Release Note
NONE

Hello @ctlaltdieliet,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Adding Daniel here to help merge this as I don't have permissions.

authors: amyblais ctlaltdieliet mattermost-build


text:
Nil pointer reference in app client

Hi, I believe I found a uhandled error case inside the appclient or rather experienced strange behavior which leads to a panic.
Unfortunately I am quite new to participating in open source projects and was not sure If I should have opened a pull request right away, sorry in advance.

@gobsej - opening an issue is the right first step (and then open a PR to fix the issue if so inclined). Adding as much info as possible to the issue (logs, code snippet, detailed behavior description,etc.) to help identify the fix is essential for fixing it in time. Thanks!

Okay, the issue lies in the getDirectChannelWith function in the mattermost_client.go:210 file.
func (c *Client) getDirectChannelWith(userID string) (*model.Channel, error) {
	channel, res, err := c.CreateDirectChannel(c.userID, userID)
	if res.StatusCode != http.StatusCreated && res.StatusCode != http.StatusOK {
		if err != nil {
			return nil, err
		}

		return nil, errors.Errorf("returned with status %d", res.StatusCode)
	}

	return channel, nil
}

The check if an error occurred is inside the check whether the statuscode of the response is a succesful one. This works if the request got an actual response but in cases where it does not (for example connection problems) the response object is nil and therefore panics.
I would suggest doing the check for the error before the status check or something like that.

source: gharchive/issue

authors: catalintomai gobsej

repo: mattermost/mattermost-plugin-apps


text:
Tsprune

Summary
Added ts-prune tool to dev dependencies in order to have a tool to report unused exported functions, var or constants.
Usage:

In webapp folder: npm run report-unused-exports
file .ts-prunerc with ignore patterns
comment // ts-prune-ignore-next can be added before a line we want to keep even if it's unused

current report
➜  webapp git:(tsprune) npm run report-unused-exports

> report-unused-exports
> ts-prune

src/actions.ts:169 - addNewTask
src/client.ts:181 - fetchPlaybookRunChannels
src/client.ts:276 - fetchUsersInChannel
src/client.ts:280 - fetchMyChannels
src/client.ts:284 - fetchUsersInTeam
src/client.ts:343 - clientRemoveChecklistItem
src/client.ts:490 - fetchStats
src/client.ts:533 - setGlobalSettings
src/client.ts:668 - clientFetchIsPlaybookFollower
src/client.ts:735 - favoriteItem
src/client.ts:762 - unfavoriteItem
src/client.ts:829 - doPatch
src/constants.ts:14 - TEMPLATE_TITLE_KEY
src/index.tsx:139 - default
src/components/checklist_item_input.tsx:139 - ChecklistItemButton
src/components/datetime_input.tsx:173 - default
src/hooks/index.ts:213 - clearLocks
src/hooks/index.ts:255 - useCanCreatePlaybooks
src/hooks/index.ts:272 - useCanRestrictPlaybookCreation
src/hooks/index.ts:290 - useExperimentalFeaturesEnabled
src/hooks/index.ts:335 - useThing
src/hooks/index.ts:414 - useDropdownPosition
src/hooks/index.ts:68 - FetchMetadata
src/hooks/index.ts:638 - usePrevious
src/hooks/index.ts:195 - useCategories
src/hooks/index.ts:26 - PlaybookCreateQueryParameters
src/hooks/index.ts:24 - useHasChannelPermission
src/hooks/index.ts:28 - useHasPlaybookPermissionById
src/hooks/index.ts:38 - PlaybookPermissionsParams
src/hooks/index.ts:6 - usePlaybookViewTelemetry
src/hooks/index.ts:14 - usePlaybookRunViewTelemetry
src/types/permissions.ts:6 - Permission
src/types/playbook.ts:97 - FetchPlaybooksCountReturn
src/components/assets/buttons.tsx:173 - UpgradeButton
src/components/assets/left_dots.tsx:182 - default
src/components/assets/left_fade.tsx:14 - default
src/components/assets/right_dots.tsx:638 - default
src/components/assets/right_fade.tsx:14 - default
src/components/backstage/new_playbook.tsx:31 - PlaybookModalButton
src/components/backstage/playbook_list.tsx:342 - useUpgradeModalVisibility
src/components/backstage/styles.tsx:25 - BackstageHeader
src/components/backstage/styles.tsx:36 - TeamContainer
src/components/backstage/styles.tsx:167 - StyledAsyncSelect
src/components/backstage/styles.tsx:227 - BackstageHorizontalContentSquish
src/components/backstage/styles.tsx:233 - RadioContainer
src/components/backstage/styles.tsx:240 - RadioLabel
src/components/modals/run_playbook_modal.tsx:240 - default
src/components/modals/update_run_status_modal.tsx:479 - default
src/components/rhs/rhs_checklists_add_dialog.tsx:57 - default
src/components/rhs/rhs_checklists_delete_dialog.tsx:72 - default
src/components/rhs/rhs_checklists_rename_dialog.tsx:66 - default
src/components/rhs/rhs_run_details_tour_dialog.tsx:146 - default
src/components/rhs/rhs_shared.tsx:21 - Footer
src/components/rhs/rhs_shared.tsx:61 - StyledFooterButton
src/components/rhs/rhs_shared.tsx:134 - SmallerProfile
src/components/rhs/rhs_timeline_placeholder.tsx:34 - default
src/components/team/team_selector.tsx:48 - default
src/components/tutorial/tours.ts:9 - AutoTourStatus
src/components/tutorial/tours.ts:55 - TTCategoriesMapToAutoTourStatusKey
src/components/assets/icons/alert_icon.tsx:21 - default
src/components/assets/icons/dot_menu_icon.tsx:12 - default
src/components/assets/icons/file_icon.tsx:10 - default
src/components/assets/icons/plus_icon.tsx:13 - default
src/components/backstage/playbook_editor/controls.tsx:133 - Share
src/components/backstage/playbook_editor/controls.tsx:154 - ArchivedLabel
src/components/backstage/playbook_runs/shared.tsx:67 - SecondaryButtonRight
src/components/backstage/playbook_runs/shared.tsx:84 - PrimaryButtonRight
src/components/backstage/runs_list/pagination_row.tsx:29 - default
src/components/backstage/runs_list/progress_bar.tsx:32 - default
src/components/backstage/runs_list/status_filter.tsx:26 - StatusFilter
src/components/tutorial/tutorial_tour_tip/index.ts:86 - useElementAvailable
src/components/backstage/playbook_runs/playbook_run/index.ts:6 - default
src/components/backstage/playbook_runs/playbook_run/rhs_info_styles.tsx:8 - Container
src/components/backstage/playbook_runs/playbook_run_backstage/playbook_run_backstage.tsx:481 - default
src/components/backstage/playbooks/metrics/metrics_run_list.tsx:16 - SortParams

Ticket Link
No ticket
Checklist

[ ] Telemetry updated
[ ] Gated by experimental feature flag
[ ] Unit tests updated

@calebroseland is anything that you'd want to change?

repo: mattermost/mattermost-plugin-playbooks


text:
Survey results

Summary
Added section to display results os previous surveys.
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-56693

@larkox I've added the empty view now. UI can be updated whenever later.

Will merge once #6 is approved.


text:
Translations update from Weblate

Translations update from Weblate for mattermost-languages-shipped/mattermost-webapp_release-5.28.

Hello @weblate,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

authors: mattermod weblate

repo: mattermost/mattermost-webapp


text:
Increase opt/llc variants available from https://godbolt.org/

godbolt.org already has the capability to take IR as input and run opt/llc on them. But, currently, only 4.0/5.0/trunk opt/llc options are available. It will be useful to extend the list of llvm versions available here (from 3.0 to 7.0).

Hi! Thanks for the suggestion. I have added every llc/opt binary we have available. I hope you find it useful! :)

Ruben,
Thanks for the real quick response!
I still only see the 3 versions as before. Does it take time for your change to be reflected on the public website?

Yes! Sorry for not mentioning it. We manually update the site at least once a week, if needed. I'll make sure to notify you when the changes hit the live site :)

authors: RabsRincon harinvidia

repo: mattgodbolt/compiler-explorer

license_source: bigquery


text:
Add support for cuprite

cuprite is a modern pure-ruby driver for Chrome headless, which replaces the selenium + chromedriver combo. It supports screenshots the default capybara screenshot method (so it already works with capybara-screenshot) but produces partial screenshots and warnings in the console (as expected):
capybara-screenshot could not detect a screenshot driver for 'cuprite'. Saving with default with unknown results.

So as it's easy I added support for the cuprite driver with the "full" option to get complete screenshot and no more warning. It works fine in my project and I also added specs :tada:
Thank you for this project and let me know if I can do anything else ;)

Thanks for this contribution, apologies I missed this when you submitted it

authors: jarthod mattheworiordan

repo: mattheworiordan/capybara-screenshot

license: mit


text:
ng-click inside a modal window

I've added the ability to edit the start/end datetimes (using datepicker) of a single event when clicking on the edit event link.
I display the event in a modal, it displays fine but the ng-click doesn't seem to have any effect when I click on it to display the datepicker inside the modal.
Should   ng-click="vm.toggle($event, 'startOpen', event)"   syntax be different when in a modal?
Anyone encountered this problem?
Thanks
html

code added to demo.js
function showEventModal(action, event) {
  $modal.open({
    templateUrl: 'modalEventContent.html',
    controller: function() {
      var vm = this;
      vm.action = action;
      vm.event = event;
    },
    controllerAs: 'vm'
  });
}

vm.eventEdited = function(event) {

 $http.get('/api/events/' + event.eventid).success(function(eventsuccess){

 showEventModal('Edited', event);
}).error(function(err){
   /* do something with errors */
});
  //console.log("eventEdited");
};

<button type="button" class="btn btn-default" ng-click="vm.toggle($event, 'startOpen', event)"></button>

should be:
<button type="button" class="btn btn-default" ng-click="event.startOpen = true;"></button>

The is-open attribute controls if the datepicker is visible or not hence you need to set it to true when clicking the button next to it as event.startOpen is what you have set as the is-open attribute.
Please note anything to do with the modal, datepicker etc has absolutely nothing to do with this calendar and any issues with those components should be raised with the folks at ui-bootstrap


text:
libnotify text arguments should be escaped

ref: http://developer.gnome.org/notification-spec/#markup

mkay, is this what would fix:
==> /home/leho/.tail/awesome-leho <==
W: awesome: draw_text_context_init:108: cannot parse pango markup: Error on line 2 char 39: 'irving@moz-3D674EBB.dsl.bell.ca' is not a valid name: '@'

mkay, is this what would fix:
==> /home/leho/.tail/awesome-leho <==
W: awesome: draw_text_context_init:108: cannot parse pango markup: Error on line 2 char 39: 'irving@moz-3D674EBB.dsl.bell.ca' is not a valid name: '@'

every time a growl notification comes in through gol and gets forwarded to awesome wm naughty libnotify based notification system, i get that error if the notification has @ characters in it (which it often does with irc hostmasks). it seems like some kind of a parsing / escaping error, and this looked like it might be related.

Ok, If the error based on @, it will be fixed with this changes.

authors: anekos lkraav mattn

repo: mattn/growl-for-linux


text:
Build releases, maybe even packages?

First off, thank you for writing this!
I'd love to see either releases or maybe even distro packages. Seems like the former is a lighter lift since it can all be done with GitHub actions.

@mattn I would be very much interested in this. Would it be possible to release a binary package in github release and possibly an aur package for archlinux?
For rust packages I have automated this. You can refer to the following files.

ci.yml.For publishing to AUR, it downloads binaries from github release. You need to create an AUR account and add a ssh key, then set AUR_EMAIL, AUR_USERNAME and AUR_SSH_PRIVATE_KEY in github secrets for the project.
genpkgbuild.sh to create PKGBUILD file to create AUR package.

You already have release working for gof so you could probably use the same ci pipelines and script to create the github release.

If someone make pull-request, I'll merge it , thank you.

authors: jc00ke mattn prabirshrestha

repo: mattn/tailscale-systray

license: MIT


text:
XPath Query on Atom feed

I am trying to do XPath query on an Atom document something like /feed/title (this returns nil currently) and eventually enumerate over the entires. The default namespace is set xmlns="http://www.w3.org/2005/Atom in the document but no prefix is set. Is there a correct way to way to use XPath with Atom or is there a way to set the prefix (so the xpath would be something like /atom:title/atom:title?

Ono should process XPath queries correctly, using whatever namespaces and prefixes as are defined in the XML document. There are passing tests that demonstrate how an Atom feed might be parsed. I can't help you with any general XPath questions; for that, I'd recommend Stack Overflow or any of the resources available online.

I've add a failing test in #27

authors: davidchiles mattt

repo: mattt/Ono


text:
Allow Collection.models to be nil

Related to #33
This PR makes the models property in Collection optional to support partial response from GET /v1/collections.

Niiice!

authors: getaaron mattt

repo: mattt/replicate-swift


text:
🛑 API auth - PROD is down

In b7659e2, API auth - PROD (https://auth.prod.api.eflow.com.ar/swagger) was down:

HTTP code: 0
Response time: 0 ms

Resolved: API auth - PROD is back up in cd9c62b.

repo: mauribesson/upptime


text:
BACKGROUND GEOLOCATION 'GETLOCATIONS' IOS REACT NATIVE

Your Environment

Plugin version:
Platform: iOS
OS version: 10.3.3
Device manufacturer and model: Iphone 6
React Native version: 0.40.0
Plugin configuration options:
BackgroundGeolocation.configure({
desiredAccuracy: 0,
stationaryRadius: 50,
distanceFilter: 0,
debug: true,
stopOnTerminate: false,
interval: 1000,
}, function () {});

Context

Hi people!
i´m developing an app for IOS with react native and i need to get the locations every second in background. But 'GETLOCATIONS' doesnt work.
Could someone help me?

Notice: this issue has been closed because it has been inactive for 91 days. You may reopen this issue if it has been closed in error.


text:
campaign builder havn't Send Text Message action option

Hi
I want to Set the text message in mautic v2.16.0 . I have set the Twilio account details also. After that as per the document below, I went to the Campaigns --> and open the campaign builder but I didn't find any option like   Send Text Message action  see below screenshot

Go to Campaigns.
Edit an existing campaign or create a new one.
Open the Campaign Builder.
Add a Send Text Message action to the canvas.

Please guide how I get this option.

Hi @nirajvara and thanks for your issue.
I'd suggest taking a look at the documentation for how to use the campaign builder: https://www.mautic.org/docs/en/campaigns/campaign_builder.html
The 'send text message' option comes up as an Action, once you have decided where your campaign starts (segment or form). So you need to create the campaign and get to the action step before you'll see the action of 'send text message'.

thanks

authors: RCheesley nirajvara

repo: mautic/documentation


text:
Increase WPM y-label range to at least 5

Fix #42.
The old "division by zero" error can be consistently triggered when one tests on a single word "aaaaaaaaaaaa" (12 a's). There will only be two wpm counts, and the error triggers if the difference is smaller than 5.

Thanks for the fix, @bolphen!

authors: bolphen max-niederman

repo: max-niederman/ttyper


text:
Add SQL parameter features

ref: #226

SQL parameters are just identifiers. Their detection and substitution should be left to the database.
Is there a reason we couldn't just allow idents from starting with $?

Good point @aljazerzen; we can definitely do that

authors: aljazerzen kiibo382 max-sixty

repo: max-sixty/prql


text:
Add tunnel's logfile to the json-state

user should be able to quickly copy-paste the log file for a single tunnel instance

should be view able when running sauced show

#25 fixes this

authors: maxdobeck mdsauce

repo: maxdobeck/sauced


text:
error message at 5-model_analysis.qmd

Max,
Congratulations on the great tutorial "Bayesian transition models for ordinallongitudinal outcomes". I really enjoyed reading it and tried to follow along using the Violet simulated data.  So far step 1 through 4 ran through perfectly.  At 5-model_analysis.qmd, the following error message was produced.  Any insight is greatly appreciated.
processing file: 5-model_analysis.qmd
|........................                           |  47% [unnamed-chunk-10]
Quitting from lines 94-109 [unnamed-chunk-10] (5-model_analysis.qmd)
Error in reformulate():
! 'termlabels' must be a character vector of length at least one
Backtrace:

stats::predict(mod, newdata, posterior.summary = "all", type = "lp")
rmsb:::predict.blrm(...)
rms::predictrms(object, ..., type = "x")
rms:::removeFormulaTerms(fit$sformula, which = "offset", delete.response = TRUE)
stats::drop.terms(te, s - ypresent, keep.response = !delete.response)
stats::reformulate(...)

Execution halted

Hello @JianWang2016 , I'm glad you enjoyed reading our paper!
I re-ran the code, but I cannot reproduce the issue you are having. Have you updated the the latest version of the "rmsb" package on CRAN? If the issue still persists, please let me know and I will look into it more.
Thank you,
Max

Thanks much Max.  That resolved it.


text:
Shadow for heading row

Hi Maxim,
I am using your lib in my project, it's excellent and I appreciate your work.
By the way, is there a way to add bottom shadow for the heading row?
Thanks

Hi! No idea... Let me know if you find a way

Table's background is transparent by default, you can play with Stack and drawing smith behind the table. Besides each row is built using TableRowInkWell - there might be some theming/styling tricks up the Flutter's sleves. Third option is try and play around with what is used in heading rows.

Hi, thanks for your suggestions, I tried using Stack, putting Container behind the table and adding BoxShadow, finally it worked.
Stack(       children: [         Container(             decoration: BoxDecoration(               boxShadow: [                 BoxShadow(                     color: Colors.black.withOpacity(0.05),                     offset:  Offset(0, _rowHeight),                     blurRadius: 4)               ],             ),             child: SizedBox(               width: double.infinity,               height: _rowHeight,             )),         Scrollbar(           child: DataTable2(...)

Thanks for sharing!

authors: TinhHuynh maxim-saplin


text:
Implement cat operation on Manifold classes.

I have added an extra test test_cat__beta_concatenation_correct_norm for beta-concatenation. The argument atol can be smaller as MD increases, so the values MD=64 and atol=1e-2 are rather arbitrary. If this is too hacky or redundant, let's remove/change the test.

Great job Diego! I think the test is fine as it is and I would like to keep it for now. Maybe we should change it a bit in the future to ensure that it cannot fail due to an unlucky outlier, but for now I don't think that will be an issue :)

authors: diegogcerdas maxvanspengler


text:
Help with charging state from attribute please

Can't seem to pull attribute value into card. The bottom entity on my screenshot should show the tablet as charging as the value for the attribute charging is currently true? Did I do something wrong?
- entity: sensor.samsung_tab10_battery
  charging: # uses charging attribute on sensor.samsung_tab10_battery
    attribute:
      name: charging
      value: 'true'

Screenshot

Version
1.6.4

what if you use
value: true

what if you use
value: true

Thanks, but that does not work either.

Please follow the examples from here:
https://github.com/maxwroc/battery-state-card#charging-state-indicators
There is no such a thing like "charging" property in entity. It should be "charging_state" instead

Thanks for the reply. I've changed the code as I mistakenly thought the attribute was charging_state which it's not. I've amended the code below but the charge icon still does not appear when the attribute charging for my sensor sensor.samsung_tab10_battery turns true.
   - entity: sensor.samsung_tab10_battery
     tap_action: more-info
     charging_state:
       attribute:
         name: "charging"
         value: "true"

I created a workaround my making another sensor.
    samsung_tab10_charging_state:
      friendly_name: "Tablet Charging"
      value_template: "{{ state_attr('sensor.samsung10_fkb_tabletui', 'charging') }}"

  - entity: sensor.samsung_tab10_battery
    tap_action: more-info
    charging_state:
      entity_id: sensor.samsung_tab10_charging_state
      state: 'True'

authors: maxwroc xbmcnut

repo: maxwroc/battery-state-card


text:
MacBook Pro 15 retina 2012 with bad NV graphics

I have MacBook MacBook Pro 15 retina 2012 with bad working NV graphics.
All solutions for removing Nvidia drivers do not allow using only integrated graphics with a working sleep and a dimmer control. When removing the Nvidia drivers and using this script (https://github.com/0xbb/gpu-switch), at the start of the system, you can use the laptop fully. Adjust the backlight and sleep work. But the script does not work on macOS 10.12.4+.
Please tell me, does your program allow me to use only integrated graphics when starting my laptop without NVidia drivers?

The primary purpose of this script was to enable AMD eGPU video acceleration and provide workarounds for bad GPUs (as I cannot test). The iGPU mux setting technically uses only integrated graphics when booting the laptop.


text:
added properties {far, interval, objects}, the same as in a-cursor, t…

…o tune raycasting performance, and apply the objects filter to limit intersection tests

Hi @c4augustus, this feature is now available in A-Frame v0.6.1 by setting . 🎉


text:
How do I enable multiple AriaNg to listen on multiple ports?

I loaded 4 aria2c-rpc, which makes it easy to manage download scenarios for different scenarios.
I was using Aria2 WebUI before, I modified the 4 Aria2 WebUI by replacing 6800 in the source code with my port, and then when I need to manage it, just open it in the browser, and I can open these 4 Aria2 WebUI at the same time.
But this method fails in AriaNg, no matter using startup parameter, or modifying the port in the source code, it is always the last loaded AriaNg parameter that takes effect, and the AriaNg that was loaded before, will be replaced by the last loaded one. In other words, no matter how many AriaNgs I load, I can only manage one aria2c-rpc at a time.
Can you tell me how to enable multiple AriaNg to listen to different ports separately?

AriaNg uses browser local storage to store all configurations, so AriaNg in the same domain shares one configuration. AriaNg supports multiple aria2 configurations and users can switch any configuration.
In addition, AriaNg also supports a special link called Command Api that can connect to aria2 directly. You can visit http://ariang.mayswind.net/command-api.html for more information.

authors: atbsi mayswind

repo: mayswind/AriaNg


text:
VARS annotation shore time display

Please display additional time data in the VARS shore GUI. When annotating we need to see the additional time ( is it 100th of a second or millisecond time unit) in the GUI -- see red box on attached screen grab. Also please make this time display bold and a slightly larger font.
Thanks,
LL

When annotating we need to see the additional time

Ok. Careful what you wish for. I'll roll this out in the next VARS release (date TBD)

authors: hohonuuli lonnylundsten

repo: mbari-media-management/vars-annotation


text:
Video jumps back a few frames when stop is pressed.

From Kris:

When playing using VARS play or fast forward and then press stop, it jumps backwards some number of frames, old sharktopoda when you pressed stop it stopped exactly at the frame without a jump backwards (Brian, I can show you this one in lab if needed) (KRW)

I confirmed this visually with just a video file playing in Sharktopoda (no VARS in the loop).

No further news from the video lab on this; so i think things are ok now. Closing the issue.

repo: mbari-org/Sharktopoda