Joplin hangs with white window for about 15-20s at start

Operating system

macOS

Joplin version

2.14.12

Desktop version info

Joplin 2.14.12 (dev, darwin)

Client ID: e354a932e6e143c782264aad4112b674
Sync Version: 3
Profile Version: 45
Keychain Supported: Yes

Revision: a364f66d4 (dev)

Automatic Backlinks to note: 3.0.3
Convert Text To New Note: 1.5.1
Get Notebook ID: 1.0.1
Insert Date: 1.0.1
Markdown table calculations: 1.0.5
Math Mode: 0.5.3
Menu items, Shortcuts, Toolbar icons: 1.1.0
Note list and sidebar toggle buttons: 1.0.3
Note overview: 1.6.0
Quick Links: 1.2.4
Table Formatter Plugin: 1.2.1
Templates: 2.3.0

Sync target

File system

Editor

Markdown Editor

What issue do you have?

I am on macOS 14.3 and node-v20.11.0

When starting Joplin (npm run start in dev mode or generating a dist and run the prod version) it hangs for about 15-20 seconds while only showing a white background. The CPU is at 100%, but nothing is logged in the dev console during that time.

I only upgraded my macOS today (10.14.6 -> 14.3). Before the macOS upgrade, I haven't seen this behavior at all.

1 Like

FWIW, my regular Windows install does that and has for a while.

1 Like

Between commits 13da286b55114438688f24b385bfca9f9f2df516 and b69d752734bffebde7e9875bbda2811742fddbe3, there was a similar issue where Joplin would take 20-30 seconds to start. Could it be caused by this? (If so, removing all .gitignored files in packages/app-desktop/build may also fix the issue).

Another possible source is the number of master keys present — on some devices each master key adds about a second to the startup time. However, I would expect text to be logged to the dev console during this (see this issue).

There is only one dir and file in this dir. Removing it seems to fix the issue.
I deleted the dir in /Applications/Joplin.app/Contents/Resources/build/defaultPlugins and Joplin starts up in 2-3s instead of 15-20s.
This seems rather strange to me. Why does one .jpl file in a dir cause so much CPU load at start and how can this be fixed?
Personally I never liked the idea of bundled plugins, but I guess that people like it, so removing the bundled plugins doesn't seem to be an option.

Nope, I don't use encryption at all, thus no master keys...

The issue was related to two .jpl files with the same ID being in the build/defaultPlugins directory:

📂 build/
| 📂 defaultPlugins/
|  | 📂 io.github.jackgruber.backup/
|  |  |  plugin.jpl
|  | io.github.jackgruber.backup.jpl

Commit 13da286b55114438688f24b385bfca9f9f2df516 changed the expected folder structure within the defaultPlugins/ directory from

📂 build/
| 📂 defaultPlugins/
|  | 📂 io.github.jackgruber.backup/
|  |  |  plugin.jpl

to

📂 build/
| 📂 defaultPlugins/
|  | io.github.jackgruber.backup.jpl

It didn't, however, clear the defaultPlugins/ directory before doing a rebuild. On a machine that had done a build with a commit before 13da286b55114438688f24b385bfca9f9f2df516, the build/defaultPlugins/ directory might still look like this:

📂 build/
| 📂 defaultPlugins/
|  | 📂 io.github.jackgruber.backup/
|  |  |  plugin.jpl

Doing a build with 13da286b55114438688f24b385bfca9f9f2df516 would then make it look like this:

📂 build/
| 📂 defaultPlugins/
|  | 📂 io.github.jackgruber.backup/
|  |  |  plugin.jpl
|  | io.github.jackgruber.backup.jpl

Finally, when Joplin starts, it tries to load both plugin.jpl and io.github.jackgruber.backup.jpl. Attempting to load two default plugins with the same ID and different .jpl files seems to have caused the very slow startup issue.

2 Likes

Thanks for the explanation.

There was definitely only one .jpl file in there, but it might have been within the old directory structure.