I have the problem that when I write in the Markdown editor, it sometimes takes a second before my changes are applied. I find this very inconvenient. What could be the cause for this?
I have only been using Joplin for a short time and have installed version 2.6.10 on Windows 10. I do not use the preview (markdown renderer). I do not have an active extension. And currently deactivated my own styles for testing.
I use Joplin on an Intel i7 Gen 8 laptop with Samsung NVMe SSD.
Well, that's odd, one thing to try is to turn off the spell checker in markdown editor: in my experience it takes a toll on performance.
A bit obvious part but when this behaviour is happening, what's your idle CPU/RAM load? Are there any other programs behaving slow when they shouldn't at that moment?
I mean if your system is bloated with processes, even newest processors/NVME may struggle under the load. Windows Defender and telemetry can make virtually any action laggy and unresponsive. To make matters worse those processes run in background and by default: good job, Microsoft!
Also, watch out for battery saving mode, it may significantly hinder the overall performance
Spell check is turned off. Windows Defender is disabled, telemetry is mostly disabled. CPU/RAM usage is low. I had an eye on it as well. Battery saving is set to performance.
I don't have such behavior in any other software like VS Code, Notepad++, LibreOffice or just in my browser.
Ok, good to know. Could you record some demonstration how does the lag look like?
Does it happen in all notes or some specific ones (like long ones, heavy on graphs etc)? if so, could you attach a sample for the reference?
Also, are there any errors/warnings in the logs produced in the moment you're experiencing the behaviour?
It would not be visible in recordings because it depends on the keystrokes and there is not a delay on every keystroke.
I will look if it happens only in specific notes. And also look up for errors in the log.
In my tests, the cause of the behavior is the length of the note. For example, here is one with 4729 lines that has only this kind content:
29.01.2022
- This is some dummy text. This is some dummy text. This is some dummy text.
- This is some dummy text. This is some dummy text. This is some dummy text.
- This is some dummy text. This is some dummy text. This is some dummy text.
> This is some dummy text. This is some dummy text. This is some dummy text.
> This is some dummy text. This is some dummy text. This is some dummy text.
- This is some dummy text. This is some dummy text. This is some dummy text.
- This is some dummy text. This is some dummy text. This is some dummy text.
- This is some dummy text. This is some dummy text. This is some dummy text.
- This is some dummy text. This is some dummy text. This is some dummy text.
> This is some dummy text. This is some dummy text. This is some dummy text.
> This is some dummy text. This is some dummy text. This is some dummy text.
> This is some dummy text. This is some dummy text. This is some dummy text.
28.01.2022
...
Is there a representation of invisible parts, or what could be the reason?
It sounds a bit odd, I have a very old and very ill Windows laptop with far lower specs than yours and it works pretty much flawlessly.
I have seen poor performance before in Joplin (on a much better PC) but normally only when I'm stressing the computer out in other ways, a couple of games when minimised caused some weird lag issues with Joplin but I mostly put that down to having little in the way of spare resources.
Its odd to me too 
EDIT:
You can copy the above block until you have about 4700 lines (I don't know how many are needed for the effect), write some gibberish words at the end of the line, and then press Shift+Home to mark the line. Then just start writing again to fill the line with new content. In most of my tests, it took almost a second for either the line marker to become visible or the new text.
Works instantly for me at >6k lines (admittedly on a decently specced desktop rather than my sickly laptop)
200k lines on the other hand, it still works but is definitely struggling, about a .1-.2 second delay to do anything. Interestingly Atom is dealing with it far worse than Joplin is.
I can reproduce the effect only from about 2000 lines. But not at 1000 lines.
In Notepad++, which I used to use for this data, there is no such data.
I used Atom specifically because it is an electron app like Joplin and wondered if the behaviour was similar in any way. Does your system resource usage take a hit when this note is open and you are making changes?
Tried my same test with Visual Studio Code, which is also using electron. But I can not reproduce it.
The full CPU load was around 10-30% during the test, with closed all visible apps.
EDIT:
It could even be that it is not my test that is the cause, but that Joplin keeps giving himself pauses for thought, which are revealed by my test.
I also disabled sync. Just to be sure.
If there is a pause, this will be indicated in the console every time:
Got ipc-message: noteRenderComplete undefined
And after around 2secs:
19:07:16: RevisionService: RevisionService::maintenance: Starting...
C:\Program Files\Joplin\resources\app.asar\node_modules@joplin\lib\Logger.js:188 19:07:16: RevisionService: RevisionService::maintenance: Service is enabled
C:\Program Files\Joplin\resources\app.asar\node_modules@joplin\lib\Logger.js:188 19:07:16: RevisionService: RevisionService::collectRevisions: Created revisions for 1 notes
C:\Program Files\Joplin\resources\app.asar\node_modules@joplin\lib\Logger.js:188 19:07:16: RevisionService: RevisionService::maintenance: Done in 165ms
C:\Program Files\Joplin\resources\app.asar\node_modules@joplin\lib\Logger.js:188 19:07:18: SearchEngine: Updating FTS table...
C:\Program Files\Joplin\resources\app.asar\node_modules@joplin\lib\Logger.js:188 19:07:19: SearchEngine: Updated FTS table in 237ms. Inserted: 1. Deleted: 0
It seems that the preview is still rendered even though only the markdown editor is visible. Could this be the reason?
Is the Preview generated in the background although not visible?
I still hope for an answer 
It seems it does, there's a plugin called Disable PDF that disables it but personally I haven't seen a huge improvement in performance when it's enabled. On another hand if you ever use wysiwyg, this plugin may mercilessly delete the note content which is possible to recover only via note history.
That solved my problem. Even though are still showing up in the log the entries "noteRenderComplete" I can no longer reproduce the pauses. Thanks for that 
So by "PDF preview" it meant the markdown renderer. I didn't know that. I wonder what the Joplin setting "Enable PDF viewer" under the Markdown item is. The naming is a bit confusing. I guess it means that PDFs are displayed in the Markdown editor, right?
I think it would be good if the plugin was named differently 
And I think it would be good to integrate that into Joplin, that when the renderer is not open, that it is not active in the background either.
The plugin basically does the same thing as toggle in settings, it was created before the author realized there was a setting for it. Are you finding that the toggle in settings is not actually removing the pdf preview? Or just that the plugin fixes performance issues and the setting does not?
I believe PDF preview in markdown plugin section and disable pdf plugin function are entirely different. Markdown plugin affects the preview of pdf attachments while disable pdf plugin disables (or you might say breaks) the rendering of both codemirror and rich text editor.
How does it break the rendering in the editors? (I'm sorry for asking, i would check myself but I'm away from my computer for the weekend and typing this all on my phone).
Based on the source code this plugin only disable the pdf preview in the viewer.