New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improving performance by reducing useless parsing #24
Comments
It could be helpful to have rough idea of bottlenecks. I tried chrome tools for nodejs but it doesn't provide useful reports for micromark. Maybe there's a flag to include or maybe it works better for browser code. |
I’ve essentially run micromark on 1mb of markdown, and then toggled a bunch of code on and off to figure out where potential bottle necks are. Hence the 13% and 28% mentioned above. |
Oh sorry I overlooked the performance speedups. 13% and 28% look good indeed ! |
this repo might be useful! https://github.com/wooorm/a-dump-of-markdown. And for these two numbers: well, block quotes and lists do need to get parsed. So 28% improvement won’t be reached. But, 1/3rd of the time is spent with ’em. |
* Remove unneeded double parse, previously needed to investigate whether flow was allowed to be lazy * Remove `lazy` field on constructs: whether a line in a construct is allowed to be lazy must now be defined by construct’s tokenizers. * Remove `.lazy()` method on effects * Fix delayed lazyness, as used by GFM tables Related to GH-24. Closes remarkjs/remark-gfm#1. Closes remarkjs/remark-gfm#3.
This comment has been minimized.
This comment has been minimized.
The document part is now fixed! |
Subject of the feature
There are two main places where parsing is done that is (potentially) useless.
This is double, because when the paragraph is closed, we will actually do the parsing.
This was done in remark too. And similar to there, it is a bit optimized.
This point in parsing markdown is rather complex, because of interplay with definitions, setext headings, paragraphs, but also lazy lines.
Removing
lookaheadConstruct
improves performance by 13%. The alternative should be possible and hopefully is not too big.document: to figure out whether containers continue, close flow, start new flow, or have lazy lines, another throwaway inspection is done.(SOLVED IN 939e90d)Removing
document
completely improves performance by 28% (although lists are complex so it some time spent there is unavoidable)The text was updated successfully, but these errors were encountered: