High CPU usage as of v4.13.0

[TheDcoder]

Hi, I upgraded to v4.13.0 recently and noticed that my fans were spinning even though I wasn't doing any CPU intensive tasks. Upon inspections it looks like one of the threads belonging to ElectronMail were the cause:

Maybe it's due to some kind of continuous event loop?

OS: Arch Linux

[vladimiry]

The selected one is a renderer/web/@chromium process but it's hard to say just by the screenshot which part of the functionality it's related to (@ProtonMail web clients or app's UI). I'm not seeing any intensive CPU load at my side (Linux).

[TheDcoder]

I think the issue started after I enabled the "custom actions" menu, but that is blind speculation on my part as it could've been a coincidence.

I can help by debugging the code on my computer. I cloned the code and installed the dependencies, but I can't find a way to run the app without building it so that I can use debugger tools to profile the code.

$ npm run start:electron:dev

> electron-mail@4.13.0 start:electron:dev
> electron ./app-dev/electron-main.js

Error launching app
Unable to find Electron app at ./app-dev/electron-main.js

Can you guide me through the debug process? I have experience with JavaScript and NodeJS, but I am not really familiar with other tools, especially TypeScript.

[vladimiry]

I thought maybe I missed properly disconnecting the MutationObserver thing which might be potentially causing the issue. But I just debugged it and can confirm it gets well disconnected (here is the code line). The minor optimization I just pushed is 9af8f4c.

Unable to find Electron app at ./app-dev/electron-main.js

It's the same build steps as listed in readme (excluding the packaging step), but at the end run yarn assets:dev && yarn build:dev. Then you start it by yarn start:electron:dev. There is at the moment no hot reload thing for the web stuff (dropped it long time ago and didn't get back yet).

[vladimiry]

Unable to find Electron app at ./app-dev/electron-main.js

Build command: yarn && yarn assets:dev && yarn build:dev && yarn clean:prebuilds && npm exec --package=electron-builder -- electron-builder install-app-deps --arch=x64

[TheDcoder]

Thanks for the instructions, but for some reason yarn is giving me errors, I ran the command from your post as well as the one from README: https://bpa.st/2QUA (output is too long so I pasted on an external site)

[vladimiry]

I missed the fact that you will need to build @ProtonMail clients by running yarn assets:dev which is a sort of headache. Better download those clients by https://github.com/vladimiry/ElectronMail/suites/4322244752/artifacts/113105326 (taken from https://github.com/vladimiry/ElectronMail/actions/runs/1447632905, ie v4.13.0 release build jobs, Artifacts section). Then unpack the archive to some place, rename the app => app-dev folder, and then copy the unpacked stuff to the project folder.

[TheDcoder]

I did what you asked, and ran yarn build:dev, but it's still not working...

TheDcoder@arch /m/d/P/J/ElectronMail (master)> yarn start:electron:dev
yarn run v1.22.17
$ electron ./app-dev/electron-main.js
Error launching app
Unable to find Electron app at /mnt/data_partition/Projects/JavaScript/ElectronMail/app-dev/electron-main.js

Cannot find module '/mnt/data_partition/Projects/JavaScript/ElectronMail/app-dev/electron-main.js'
Require stack:
- /mnt/data_partition/Projects/JavaScript/ElectronMail/node_modules/electron/dist/resources/default_app.asar/main.js
- 
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

TheDcoder@arch /m/d/P/J/ElectronMail (master)> ls app-dev
assets  electron-main  electron-preload  web

I think we can debug this more efficiently if we can communicate in real-time, do you use IRC or Matrix?

[vladimiry]

My bad, I didn't update the start:electron / start:electron:dev npm scripts after recent ./app/electron-main.js => ./app/electron-main/index.cjs rename. So use direct run, like npx electron ./app-dev/electron-main/index.cjs. Done now in 33c1e56.

[vladimiry]

I think we can debug this more efficiently if we can communicate in real-time, do you use IRC or Matrix?

Sorry, but I'm ready to provide live support at this time.

[TheDcoder]

Direct run worked... but unfortunately the native build artifacts were compiled with an older version of node, so I can't use them:

Error: The module '/mnt/data_partition/Projects/JavaScript/ElectronMail/node_modules/spellchecker/build/Release/spellchecker.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 93. This version of Node.js requires
NODE_MODULE_VERSION 99. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).
    at process.func [as dlopen] (node:electron/js2c/asar_bundle:5:1800)
    at Object.Module._extensions..node (node:internal/modules/cjs/loader:1199:18)
    at Object.func [as .node] (node:electron/js2c/asar_bundle:5:1800)
    at Module.load (node:internal/modules/cjs/loader:988:32)
    at Module._load (node:internal/modules/cjs/loader:829:12)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13331)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:94:18)
    at Object.<anonymous> (/mnt/data_partition/Projects/JavaScript/ElectronMail/node_modules/spellchecker/lib/spellchecker.js:3:16)
    at Module._compile (node:internal/modules/cjs/loader:1116:14) {
  code: 'ERR_DLOPEN_FAILED'
}

I will try building ProtonMail myself.

[vladimiry]

the native build artifacts were compiled with an older version of node, so I can't use them:

A native dependencies. You need to run yarn clean:prebuilds && npm exec --package=electron-builder -- electron-builder install-app-deps --arch=x64 (was listed in previous message).

I will try building ProtonMail myself.

Nope, it's not about @ProtonMail. Those are native dependencies used by the app.

[TheDcoder]

Oops, my bad, I missed that command. I ran it again and the app is running 👍

I have encountered another issue though, I am getting this error while logging in;

Failed to resolve the "web-client" bundle location by "https://app.protonmail.ch" API entry point value

My fan is not spinning at full speed yet, so the resource-consuming loop isn't triggered at this point.

[vladimiry]

Failed to resolve the "web-client" bundle location by "https://app.protonmail.ch" API entry point value

Make sure you properly unpacked the @ProtonMail web clients (see #461 (comment)). After doing that unpacking/renaming you need to run yarn assets:dev again so the script takes client from the ./output/git/backup and puts it into ./app-dev/webclient.

My fan is not spinning at full speed yet, so the resource-consuming loop isn't triggered at this point.

At this point it's only the app stuff is running, no @ProtonMail involving yet.

You are almost there.

[TheDcoder]

Awesome, thanks for assistance, I am able to run the app now.

But I couldn't reproduce the 100% CPU usage... so I tested with the pre-built release version and it still is eating up 100% of the CPU. It only happens once I load an email, so I guess it has to do something with the specific version/build of the ProtonMail stack?

@vladimiry Did you test the release build? Perhaps you might be able to reproduce it too.

[vladimiry]

@vladimiry Did you test the release build? Perhaps you might be able to reproduce it too.

See #461 (comment)

I'm not seeing any intensive CPU load at my side (Linux).

[TheDcoder]

Sorry for not explaining properly, I mean the exact binaries that are uploaded for the release, I think a very specific version of ProtonMail stack might be responsible...

Your dev environment might be using a different stack which doesn't have this "bug".

[prestr]

I too have high CPU usage since the update.
I'm on Windows 10 with a i7700k and ElectonMail is is using 13-17% CPU, even when its closed to the tray.

[vladimiry]

Can you test the build shared in #460 (comment) (it's v4.13.0 but with downgraded @electron)?

[TheDcoder]

@vladimiry This build is working without performance issues! Hardly any CPU is being used during idle now :)

[vladimiry]

Great, so you have got a workaround for now. It means that the issue lies somewhere in @electron since 16.0.0-beta.8 => 15.3.1 downgrade did the trick.

[prestr]

Just confirming that the build is working for me too on Windows 10.

[vladimiry]

So it's not system-specific as the issue reported to be happening on Linux and Windows 10.

I will consider publishing a new release with downgraded @electron if more reports get posted here. But would prefer to first make a new build based on a stable @electron v16 (it's going to be released next week).

[Uj947nXmRqV2nRaWshKtHzTvckUUpD]

I am experiencing high cpu usage on Windows 11 as well since last update

[vladimiry]

@fusionneur does #461 (comment) help?

[vladimiry]

Can someone who had CPU usage problem before test this v4.13.2 RC build?

Changelog draft:

• Bundle proton-vpn-settings web client into the app (Can't enter in ProtonVPN #470).
• Update @ProtonMail web clients stack. The session.bin file produced or modified by the v4.13.2+ app version won't be compatible with the previous app versions.
• Upgrade @electron.

[brandon-doornbos]

Just tried the RC, and the issue has returned on my Arch Linux machine. One of the processes is again maxing out one thread. (Even after a restart)

Edit: Also happens on my Arch laptop.

[vladimiry]

@brandon-doornbos, thanks. That RC build is based on recently released @electron 16.0.6 which includes @chromium bump so I thought maybe the issue got fixed somewhere upstream in @chromium. So will be releasing a new version built on old/v15 @electron.

Edit: Also happens on my Arch laptop.

Doesn't happen to me on Linux for some reason.

[brandon-doornbos]

Weird, what distro do you use?

Edit: Ok, maybe it's just really hit or miss, there are like 3 different issues about cpu usage on the electron GitHub, one on Windows 7 and 2 on MacOS from a quick glance.

[vladimiry]

It's Manjaro (Arch based). I would not ask someone to test the build if I could reproduce the issue at my side.

To face the issue, do I need to perform a specific action in the app or just start it and login into the proton account?

there are like 3 different issues about cpu usage on the electron GitHub, one on Windows 7 and 2 on MacOS from a quick glance.

Please list them here. I don't believe though that @electron contributors will start actively looking into it until the minimal repro project gets provided (which normally hard to do for such kind of issues).

Btw. Notice the below note. So if you use persistent session feature you will have to keep using that RC build or login again if you prefer downgrading to a stable release (new release is coming soon). The reason is that @ProtonMail changed the session credentials storage format in an updated web clients.

Update @ProtonMail web clients stack. The session.bin file produced or modified by the v4.13.2+ app version won't be compatible with the previous app versions.

[brandon-doornbos]

To face the issue, do I need to perform a specific action in the app or just start it and login into the proton account?

I tried it fresh on my laptop today, and the only thing I did was install the RC pacman file and then login. This did not do anything so then I closed the app and opened it again and upon logging in, one full thread utilized. On my PC, where I already had the previous version, I just installed the RC and it immediately did it upon logging in.

Please list them here.

electron/electron#31916, which lists siyuan-note/siyuan#3507, which I can't read. The other one I found was for a different version, sorry.

I just can't fathom what would cause this, as it is consistently happening to both my Arch machines but not your Arch based machine.
Is there something else that I could do to help with finding the cause? Are there debugging tools or something?

[vladimiry]

Are there debugging tools or something?

The app's code need to be compiled in "dev" mode in order to be able to open dev tools (I think it's a web/renderer process is a problematic one). There is no documentation on this matter yet. Building and running the app in dev mode is not a complex process but time-consuming, similar to what described in https://github.com/vladimiry/ElectronMail#building-locally. Debugging of the main process can be achieved as listed in https://www.electronjs.org/docs/latest/tutorial/debugging-main-process but I tend to think that it's not the main process causes the problem.

[vladimiry]

I think it's a web/renderer process is a problematic one

Yes it's clear that it's a renderer process since we got screenshot provided in #461 (comment).

[vladimiry]

What about this build (Electron: 15.3.4)? if it runs well I will be publishing it as a new release then.

[brandon-doornbos]

Yep, no problems.

BTW, i built the thing and a dev build, so I'll see if I can find something.

[brandon-doornbos]

Hello again, well I could not find anything with just the normal debugging tools, and if I would want to debug electron itself, well, debug symbols. The whole electron repository doesn't even fit on my drive so that's a no.

Let's hope that this gets fixed accidentally someday.

Edit: By the way, keep up the great work, this is an amazing project and your support with this issue has been great :).

[vladimiry]

What about this build (built from wip-electron-18 branch on recently released @electron v18.0.0-alpha.1)? Still causing issue?

[brandon-doornbos]

Yep, this one has the high usage again :(.

[vladimiry]

Thanks for the test. So it's confirmed that newest @electron v18 alpha is unfortunately also affected.

[vladimiry]

@brandon-doornbos can you test this build? It's the same v4.13.6 release but assembled on recently published @electron v19.0.0-alpha.1. Anyone else is also welcome to test the build.

[brandon-doornbos]

The high usage does not seem to affect me with this build, so it may actually be fixed. We probably need other people from this thread to confirm it though. (I'm still on the same platform)

[vladimiry]

The high usage does not seem to affect me with this build, so it may actually be fixed.

Thanks. So hopefully the next app release will be utilizing @electron v19 runtime. If possible please keep using this build (same as v4.13.6 but with bumped @electron).

[Uj947nXmRqV2nRaWshKtHzTvckUUpD]

no cpu usage for me as well (~0.5% cpu while in tray with multiple accounts)

[brandon-doornbos]

If possible please keep using this build

Good call, after using the build for a while longer, the problem seems to have returned. A renderer process is again fully stressing out a single core :(.

[vladimiry]

Asking to share the CPU and GPU type used (including integrated graphics) as it might potentially help to narrow down the scope.

Also maybe someone who can reproduce the issue could try running the app with disable-like GPU/rendering-related command-line switches from the https://peter.sh/experiments/chromium-command-line-switches/ list (you would run the in-page search by the gpu / renrerer keywords to locate those switches). This list is unfortunately quite huge.

[brandon-doornbos]

I've got an R5 1600 and an RX480, so no integrated graphics.

It consistently hits one core when I start the app, then if I switch to another account and close the app, it often fixes itself. So maybe it is related to residual processes.

The behavior is the same in X11 and Wayland.

List of command line arguments I've tried:

• --disable-mojo-renderer
• --disable-gpu
• --disable-new-content-rendering-timeout
• --disable-partial-raster
• --disable-renderer-accessibility
• --disable-renderer-backgrounding
• --enable-nacl
• --enable-oop-rasterization
• --extension-process
• --font-cache-shared-handle
• --font-render-hinting
• --instant-process
• --renderer-cmd-prefix="valgrind --tool=callgrind"
• --disable-accelerated-2d-canvas
• --disable-frame-rate-limit
• --disable-gpu-compositing
• --disable-gpu-driver-bug-workarounds
• --disable-gpu-early-init
• --disable-gpu-memory-buffer-compositor-resources
• --disable-gpu-memory-buffer-video-frames
• --disable-gpu-process-crash-limit
• --disable-gpu-program-cache
• --disable-gpu-rasterization
• --disable-gpu-sandbox
• --disable-gpu-shader-disk-cache
• --disable-gpu-vsync
• --disable-gpu-watchdog
• --disable-threaded-compositing
• --disable-zero-copy
• --enable-gpu-debugging
• --enable-native-gpu-memory-buffers
• --gpu-launcher="valgrind --tool=callgrind"
• --ignore-gpu-blocklist
• --in-process-gpu
• --use-fake-mjpeg-decode-accelerator

[vladimiry]

Can someone test the electron v19 based build (build log / changes)? There is a hope that the following changes will make some effect: updated proton clients, updated electron, dropped MutationObserver use in the project.

[brandon-doornbos]

Well this may finally be it :).
It has not yet shown any signs of excessive resource usage, even after a restart and some usage.

[vladimiry]

Thanks for the feedback. If possible, please keep using this build for a while. Hopefully, the next app release switches to the recent @electron version (v15 => v19).

[brandon-doornbos]

Still haven't found any issues, after multiple days, many restarts and actual usage.
We probably need a second person from this thread to confirm, but as far as I can see it's fixed.

Also, thank you for continually thinking of us :).

[prestr]

Testing out again today on Windows 10. Only been ~5 minutes but so far looking fine. I'll report back.

[prestr]

Testing out again today on Windows 10. Only been ~5 minutes but so far looking fine. I'll report back.

Looking fine, pretty confident the issue is resolved in v5.0.1.