Editor lags badly when note contains many triple backtick blocks

[nickrbogdanov]

I have a note that's about 1500 lines long, which has 50+ "```" preformatted blocks containing code, log snippets, and other miscellaneous data. I noticed that as this note grew, editing performance got worse and worse. For instance, just typing a few characters on a fresh line, then highlighting them and deleting them, took 8+ seconds. This is a problem on macOS and on Linux.

I opened up Help -> Toggle development tools, started Profiling, and reproduced the problem. It pointed to compileLanguage() in highlight.js as the culprit. Apparently, letting highlight.js autodetect the syntax highlighting scheme requires compiling or evaluating a massive number of regular expressions.

A simple repro case is to paste 1000 instances of a simple preformatted text block into a note, and then try adding/deleting text from the note:

As a workaround: when I disable syntax highlighting on each block, the performance issue goes away:

This may be similar to #1649

[melsonic]

@nickrbogdanov can you comment the version of Joplin that you are using?

[nickrbogdanov]

I just reproduced the problem on Linux using the test case above. That version is:

It's from the Ubuntu snap, which looks to be a few months old: https://snapcraft.io/joplin-desktop

I also see it on macOS:

Joplin 2.9.17 (prod, darwin)

Client ID: 40b8b886d4c4461b8eedb5e2cd83e6b8
Sync Version: 3
Profile Version: 41
Keychain Supported: Yes

Revision: a84a8e7

If I navigate to Joplin -> Check for updates..., it tells me I'm on the latest release.

[melsonic]

I just reproduced the problem on Linux using the test case above. That version is:

It's from the Ubuntu snap, which looks to be a few months old: https://snapcraft.io/joplin-desktop

I also see it on macOS:

Joplin 2.9.17 (prod, darwin)

Client ID: 40b8b886d4c4461b8eedb5e2cd83e6b8
Sync Version: 3
Profile Version: 41
Keychain Supported: Yes

Revision: a84a8e7

If I navigate to Joplin -> Check for updates..., it tells me I'm on the latest release.

I have 5 code blocks of 2367 lines of each but editor is working file, I agree that scrolling becomes a bit slow but it is understandable. I also tried it with 50 code blocks containing ~130 lines each.

here is the jopling version details that am using

Joplin 2.9.17 (prod, linux)

Sync Version: 3
Profile Version: 41
Keychain Supported: No

Revision: a84a8e771

[nickrbogdanov]

Could you please try pasting my test case into a new note: https://gist.githubusercontent.com/nickrbogdanov/2da682ea0620dfbd137df8927d5834b7/raw/76f913b04fe0b31a26c27a90958a8bc064627e83/gistfile1.txt

[melsonic]

Could you please try pasting my test case into a new note: https://gist.githubusercontent.com/nickrbogdanov/2da682ea0620dfbd137df8927d5834b7/raw/76f913b04fe0b31a26c27a90958a8bc064627e83/gistfile1.txt

Okay, just tried and found editing text becomes lazy, but it is also understandable. And on the other hand, It would be a rare case where a note will contain 1000 code blocks. That's because it will also be harder to navigate across such a large note.
@laurent22 do you have anything to suggest here?

[nickrbogdanov]

Two things:

1. This is just an easy repro case for the issue. I saw the same lag in a much smaller note, which is why I profiled it and came up with this repro case so you could see the same issue I'm seeing.

2. The problem is not that the note contains 1000 code blocks. The problem is the syntax autodetection. If you override autodetection, the lag goes away: https://gist.github.com/nickrbogdanov/c086be9b511db63a68b34d6f7e713dbb

[laurent22]

Thanks @nickrbogdanov, that's good to know it's related to syntax autodetection, it might mean we can fix it by caching something

[laurent22]

Well about 4 years ago I've implemented an optimisation to fix that exact problem, but somehow it disappeared over the years after multiple refactorings. I've enabled it again and it seems to work as expected (went from taking 2000ms to render on my machine to 20ms)

[nickrbogdanov]

Hi, any chance this could be merged into the next 2.10.x release? Looks like it is in the dev branch but not the release-2.10 branch.

[laurent22]

No sorry, I would prefer if it goes through a prerelease in case there's any bug we didn't expect