Keystrokes are slow in the beta version

Bug report

Hi, I usually create long markdown files to keep track of my work.
When I enter a key from the new beta version, the rendering stops for a long time, which is frustrating.
I would like to know if this is a problem or if it is affected by some debug mode.

related issue: Memory consumption is very high - #18 by Seito_Tanaka

Environment

  • Platform: macOS
  • Platform version: Ventura 13.1
  • App Version: v5.6.0 beta.0

How to reproduce

  1. Create a note that repeats the following lines 3,000 times
    - aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    
  2. It freezes every time I enter the text

Hi Seito-san,

Thanks for the report.
I managed to reproduce the performance issue.

So, it looks like the new Markdown parser (mdast-util-from-markdown takes a longer time to parse Markdown.
The performance vs extensibility is discussed here:

I think, is performance: micromark is currently slower than what used to be in remark-parse. About 50% slower. That is significant, but a) micromark is also better than what used to be in remark-parse, b) it’s still fast to parse a big book, c)the problem with syntax trees is always the syntax trees, not the parsing—if remark is slow, that’s because a plugin is slow, not the parsing, and d) there is some low hanging fruit (see open issues).

Unfortunately, it is hard to solve this from the app side.

The problem here is that the rendering process locks the whole UI while parsing.
I’ll check out a solution using Web Worker.
But I’m worried that it will result in losing the extensibility of the Markdown parser… :confused:

BTW, you said you usually create long markdown files. What are the content of them? Log files?
In my note-taking workflow, I haven’t ever written thousands of lines, even with some server logs.

Do you edit the long notes in the side-by-side mode?
I guess the rendering process can be deferred more when in the edit mode so that it won’t affect the editing experience as a workaround. Currently, it’s 100ms but it could be 1,000ms when in the edit mode.

Thank you for the information :slightly_smiling_face:
The way I use my notebook may be unique, but I keep a single file for each project I work on, whether work or personal, and I keep all the information I need to make decisions in the past. This is my favorite style because it makes searching and following the chronological order easier.
I don’t usually use side-by-side with my Apple M1 Pro 8core.

Thanks for letting me know your workflow. Yeah, that sounds unique!
Okay, so, extending the rendering delay would solve the issue. I’ll try it in the next version.

BTW, it made me think of trying the Rust Markdown parser by the same author of Micromark :thinking:

Yes, it will lose the parser extensibility but it will greatly improve the performance.
It is still in alpha though, a very interesting project. I’ll keep my eye on it.

1 Like

Can you try v5.6.0-beta.1, which has a longer delay for the edit mode?

Great! My problem was completely resolved. I can write comfortably in edit mode.

1 Like

Cool! Thanks for letting me know.