High CPU usage when sync fails using webdav

[yuyichao]

I currently have a fairly unreliable network (e.g. this issue page takes a few refresh to load...).
As expected, the syncing function may fail from time to time.
However, it seems that the sync frequently get stuck with high CPU usage and does not response to the "cancel" button.
Restarting the app is the only way I have currently found to fix the issue.

Environment

Joplin version: 1.2.6
Platform: Linux
OS specifics: Arch Linux

Steps to reproduce

Setting up a webdav sync with an unreliable network should do. However, I'm not really sure what kind of "unreliability" I have = = ....
FWIW, it's the xfinitywifi hotspot, but I suspect it's a rather local problem...

Describe what you expected to happen

The sync may fail or timeout. It should not have high CPU usage. Should be cancellable.

Logfile

Most of the entries below happens well before the hang. The hang does not seem to produce any special error messages. (if it does it'll probably break out of the dead loop.....)

CommandService::execute: synchronize {syncStarted: false}
28[Violation] 'setTimeout' handler took <N>ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 52ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 70ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 59ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 66ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 66ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 59ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 50ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 73ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 68ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 58ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 54ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 60ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 74ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 75ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 72ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 51ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 84ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 83ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 51ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 79ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 72ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 75ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 53ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 75ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 73ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 56ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 50ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:47 [Violation] 'setTimeout' handler took 67ms
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:141 CommandService::execute: synchronize {syncStarted: false}
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:141 CommandService::execute: synchronize {syncStarted: false}
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:141 CommandService::execute: synchronize {syncStarted: false}
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:141 CommandService::execute: synchronize {syncStarted: false}
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:141 CommandService::execute: synchronize {syncStarted: false}
/usr/share/joplin/resources/app.asar/lib/services/CommandService.js:141 CommandService::execute: synchronize {syncStarted: false}

[hydrandt]

Same issue here. I'm in China, my webdav server (seafile) in Sweden. Sync often hangs, takes very long, the Cancel Sync operation also takes very long (2-3 minutes), but usually does actually finish.

While syncing, Joplin uses about 30% of single core on my system (about 20% gpu-process, 10% renderer), that's on i7-8550U, running at the time of the sync at 800 - 1000 MHz - so actually not that much, but it is still the most CPU hungry process in my system.

[pure speculation] As it is actually coming from the gpu-process and renderer, is it actually possible that the load is caused by the rotating sync icon? This actually might indeed be the case as the CPU usage drops immediately after I close the Joplin window (with the tray icon enabled).

[yuyichao]

Yeah, I also have the same suspition (CPU usage) after looking at the busy process and the profile from devtool.

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[hydrandt]

This is still an issue, CPU usage is high when the sync button is animated (sync ongoing) and joplin window is open. If window is closed (icon in tray), the cpu usage immediately drops.

[yuyichao]

Also the issue that a failed sync sometimes can't be cancelled is also still there...

[keitarobr]

I'm having the same issue here (Ubuntu 18.04). Minimizing to tray stops CPU usage but I have to close and open the app to restore synchronization.

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[yuyichao]

Still happening.

[dylanmorroll]

Yeah I think I'm experiencing something similar! Laptop fans were whirring away and noticed Joplin was consuming 64% of my CPU which I've never experienced before - I also moved recently and have a pretty unstable network so it seems unlikely that it's a coincidence!

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[dylanmorroll]

My internet has been stable recently so haven't had chance to test it.

[gerroon]

I am suspecting that actually Google is running remote testing on these electron apps. I get high cpus for no apparent reasons, even when I have not updated the notebook for 2 days

@joplinapp-desktop --type=gpu-process --field-trial-handle=403648123457212345,12345863150913512345,123456 --enable-features=WebComponents

https://textslashplain.com/2017/10/18/chrome-field-trials/

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[yuyichao]

Still high CPU usage during update

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[hydrandt]

Still the same - even when syncing against joplin server. Around 30% CPU (thinkpad x1 carbon 6th gen i7) used by the gpu-process.

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.

[hydrandt]

This issue is still relevant. I switched to self-hosted joplin server, the sync still often hangs for many minutes. While the sync spinner is rotating, Joplin consumes 10-30 % cpu:

Remedy is closing the application window and hiding it in tray as it is syncing.

What would be great:

1. possibility to disable the animation that seems to take so much cpu
2. fail faster if connection is hanging