Desktop UI is too slow to work efficiently

Joplin is a great app and is very suitable for my workflow. But, the more I depended on it, the more I began to notice the slow response of its UI.

For example, I frequently switch notes for viewing and editing. The switching time always takes 1 to 2 sec (sometimes more). It is too long and breaks my concentration and lowers my efficiency. It is often said "1.0 second is about the limit for the user's flow of thought to stay uninterrupted".

I hope Joplin would be as fast as VS Code. Of course, I understand that Joplin has many factors (such as plugins) that prevent it from being faster.

Is this just a problem with my PC? Does anyone else think the same way?

3 Likes

All my installs are pretty much instant

Same here, it's very fast for me but I only use one plugin.

Same here. Joplin works fluently on my desktop pc.
My enviroment is this:

Version: Joplin 2.6.10
OS: Windows 10 Home Version 21H1
System: Processor: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz
RAM: 8,00 GB
System type: 64-Bit

Sync status (synced items / total items)

Note: 856/856
Folder: 33/33
Resource: 2828/2828
Tag: 230/230
NoteTag: 2151/2151
Total: 6181/6182

HTH

Used to be slow on my old laptop. Much better now on a new PC.

Examples of my environment are here:

Measurement results: (measured by DevTool Performance Analyzer)

  • (A) "1. Welcome to Joplin" note (2.6k characters): 0.8sec

  • (B) a text-based note (16k characters): 1.6sec

  • Conditions:

    • Switching two notes (A) and (B) in different notebooks.
      • Switching between different notebooks are slower than in the same notebook.
    • Before the measurement, they are displayed several times as warming up.
    • Spell checking: disable

Environment:

  • Joplin version: 2.6.10
  • Plugins:
    • Conflict Resolution, Favoriates, Insert Data, Kanban
    • Markdown Table: Colorize, Markdown Table: Sortable, Math Mode
    • Note Tabs, Note overview, Outline, Persistent Editor Layout
    • Quick Links, Resource Search, Table Formatter, Tempaltes, turnToChart
  • Editor & Layout
    • Markdown Editor and Viewer (Split)
  • OS: Win10 Pro 21H2
  • PC: Core i5-4670 (3.40GHz), 32GB Mem, 4TB SSD

Sync status (synced items / total items):
Note: 1079/1079
Folder: 74/74
Resource: 232/232
Tag: 112/112
NoteTag: 3260/3260
Revision: 740/740
Total: 5497/5497

1 Like

Low power user here

specs
  • Joplin 2.6.10 (prod, linux)
  • Intel i3 M 370 (4) @ 2.399GHz
  • RAM 8GB
  • SSD 400 mb/s writing

Sync status (synced items / total items)

  • Note: 4791/4791
  • Folder: 150/150
  • Resource: 5207/5207
  • Tag: 21/21
  • NoteTag: 177/177
  • MasterKey: 0/0
  • Revision: 8/8
  • Total: 10354/10354

I do understand what you mean, I used to experience the same 1-2 seconds lag and it was getting old. Especially on the contrast that many other electron applications are much more responsive.

I did some tweaking and it went down to 0.3-0.9 seconds per action. It's not pleasant to see a visible lag but at least it is better than it was before.

Tweaks I did
  • turned off the spell checker in markdown editor
  • Disabled note tabs
    // I think there was something off with outline plugin and backlinks, but I'm no longer sure
    // I also think Persistent Editor Layout adds a few ms when switching a note, but I kept it anyway
  • Moved to flatpack from appimage (doesn't affect performance but starting time went down from 30s+ to just 7s)

I still wouldn't dare to click through 100 notes in a row (happens while searching). But I can do day to day tasks just fine.

3 Likes

Thank you for nice tips.

turned off the spell checker in markdown editor

Oh... The above results are when shell checker is already off.
If it is enabled, things go worse.

  • note (A) 0.8sec -> 2.0sec
  • note (B) 1.6sec -> 2.0sec

Disabled note tabs

I cannot live without Note Tabs...

3 Likes

I think the problem here is also the tags

1 Like

When I saw the issue before, I reviewed relevant codes. Indeed, some codes relevant to tags are inefficient in computational complexity.

If #tags > 1000, it will be a problem. However, if #tags < 100, it seems that it has not so large impact on the performance of note switching.

Of course, the inefficiency of adding/deleting tags is another matter.

Yes there are two problem, adding/deleting of taggs and the processing of notes with tags

@ken1kob, it might be worth disabling all the plugins, and if you find the response has improved to your satisfaction, then to reintroduce the plugins one at a time to see if particular one/s cause slow down?

Thank you, @johano.

I checked and found the following are the top 3.

  • Spell Checking
  • Note Tabs plugin
  • Outline plugin

Other plugins also worse the response cumulatively, but their impacts are relatively low.

I can drop spell checking, but Note Tabs and Outline is necessary for me. Sigh...

Very interesting.

Well, honestly I'm not surprised that it improved starting time, I just couldn't predict that it can run 4x faster than the official package.

And yeah, I get that you're using Windows I.e. it's not applicable to you, just thought that fellow Linux folk might stumble upon the post searching for mysterious issue with the overall responsiveness.

By the way, do you experience a memory leak as well? Seems to be the common problem with electron on Windows.


Issues with performance are rarely discussed here cause y'know we're running an electron app. And it's hard to search for this stuff because you don't know what's the issue, just the symptom whereas the terms describing it are very generic.

Also the fix require an intimate knowledge of codebase and much willpower illustrating the benefits of a solution to people running high spec rigs.

I thought one day I might try my hand at measuring performance as part of integration testing project but again, codebase and the willpower are out of my reach.

Interesting. I use the same 3 plugins and some more. And my system (:arrow_up:), which also runs windows, looks weaker than yours. But as also described above, I experience no slow reactions. Except at starting the program (I forgot to tell you thatearlier), but that doesn’t matter to me.

I have only very limited inside in hardware related topics, but did you check your system monitor while using Joplin to see if there are enough resources available for it? E.g. I learned that Joplin takes a big share of RAM for example. I think you should be fine with your 32 GB of available RAM, but just in case…

Such a difference under similar environments is really interesting.
This may be a strong clue to a solution.

Yes. There was no resource shortage observed. As shown in the below images, most of time is consumed by Joplin's code execution.

If you don't mind, could you please measure the performance of notebook switching?
The procedure of my measurement is as follows.

How to measure:

  1. Open "DevTool" from "toggle development tools" in Help menu in Joplin.
  2. Select "Performance" tab in DevTool.
  3. Click the record button (a black circle at the left top corner in DevTool to start a measurement.
  4. Do actions which you want to measure in Joplin.
  5. Click the record button again to stop the measurement.
  6. After several seconds, the result is shown in DevTool (like the below images).
  7. Find an execution you measured and calculate its elapsed time.

Examples of measurements: (measured in Joplin 2.7.10) new!!

  • Switching to "1. Welcome to Joplin" from a note in the same notebook: 916msec

  • Switching to "1. Welcome to Joplin" from a note in a different notebook: 2782msec

1 Like

I agree. Persuading people with high-spec PC to understand the necessity of the performance improvements is strenuous.

If there are people suffering from performance problems with low-spec PCs like me, I want to hear and collect their opinions more.

As above stated, some people forgoes some plugins because of performance issues, even if they are useful. Isn't this a sad thing for the community?

4 Likes

I don't mind and I can follow your introduction, but I can't identify my action to measure it. So how do I identify my click on a new note as a starting point? And of course the end of measurement too...

I see. The detailed procedure of my action (Switching to "1. Welcome to Joplin" from the same notebook) is:

  1. The measuring target note is "1. Welcome to Joplin" in "Welcome! (Desktop)" notebook, which is the default notebook when a profile is newly created.
  2. Before a measurement, select "2. Importing and exporting notes ↔️" in in "Welcome! (Desktop)" notebook.
  3. (Start recoding) Click the Record button in DevTool.
  4. Wait three seconds.
  5. (Action) Select "1. Welcome to Joplin" note by clicking a note list item in the NoteList panel.
  6. Wait five seconds.
  7. (Finish recording) Click the Record button in DevTool again.

Now, you will see a performance view like the above image in DevTool.
In the upper part of the view, you can find "CPU" row, and in the row, you can find a yellow mountain. It means the execution of note-switching.

Next, by dragging and mouse-wheeling, adjust the "Main" row to magnify whole the yellow mountain. After adjustment, the first task of the execution will be "Event: click" in the Main row, but the end task varies case-by-case.

At the bottom row, if you select "Summary" tab, you can find the elapsed time of the execution in the "Main" row, and its breakdown list is displayed.

1 Like