The node placement is messed up, but it's handled in <> repo, if you can create an issue there, that'll be tracked correctly.

Regarding performance, I'm not able to recreate it locally in firefox. Change seems to be instantaneous.

We could try performance profiling your browser and see what's the issue.

This is one of those laggy frames.

the bar is 300ms long, and is spent mostly in render(), mf(), _t(), f.exports()

Zooming in further indicates that most time is spent inside "Recalculate Style" and Chrome is showing me the warning "Forced Reflow is a likely performance bottleneck".

Regarding it, I found https://stackoverflow.com/questions/37183017/google-devtool-timeline-forced-reflow-is-likely-performance-bottleneck, so probably the code is reading a variable that it should cache instead.

@AntonioNoack, can you check if there is any difference in https://deploy-preview-917--mermaidjs.netlify.app/ ?

I just checked, and I get the same lag issues there.

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

When the flowchart gets a little bigger, then the performance drops noticeably. I type quite fast, but there is a delay in rendering charts. The video shows as if I'm typing with pauses, but this is not so, it's just that the live editor can't cope. I have a powerful PC with Win 10.

Is there a chance that performance will improve?

By the way, this extension for the VSC do a good job with rendering and working pretty fast, but not complete:
https://github.com/mjbvz/vscode-markdown-mermaid

@zloid, does turning off auto sync help the performance of the editor?

@sidharthv96 yes, with sync is disabled, performance is better.
It would be nice if there was performance even with sync is enabled :)

By the way, thanks for your work!

Hi,
Regarding the performance issue I experience the same (Firefox on Ubuntu) and this is clearly related to the time cost to re-render the diagram. No issue when auto-sync is off.
I think this is because the diagram is rendered every keystroke, but instead we should adopt a less aggressive syncing strategy:

• Every time a keystroke is typed: We mark the diagram as dirty
• If there is another keystroke within 0.5 second (example value): Reset the 0.5s timer and mark the diagram as dirty is necessary
• Otherwise, when the timer ends without an additional keystroke: Re-render the diagram and mark it as not dirty anymore.
• Additionally, to avoid huge out-of-sync if the user is taping continuously, every 5 second for example re-render the diagram if it's dirty. It may cause a small lag but when taping continuously, it's better to have a small lag every 5 second than at each keystroke.

On the other hand, I doubt that the diagram render is really async despite the name of the function used (source), because of this await here. Why not using .then() instead, to make the call truly asynchronous?

The poor performance could be improved with a simple debounce. If I type a word such as Redirect, it seems to try to render the graph for every keypress, which kills the performance. Is there already a debounce in place? It doesn't seem like it from my end.