-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
Parser is too large/bloated #56
Comments
yea, I knew it was very likely the performance getting a hit , because of the RegEx use, but didn't know how to benchmark or analyse! It is always good to have some number to compare with. I am really not sure what about any alternatives tbh, any ideas? I believe you were working on a blade parser yourself with scanners, any luck there? That |
Yeah I have some ideas that I need to play around with including:
|
I am not sure how extending alone would work in terms of I actually got the If there is anything at the bottom of the I tried to document it as much as I could using comments but yea, it's some ugly code, esp parenthesis balancing recursion bit! |
Yes, but interestingly enough the html state count is only 94 bytes (makes heavy use of the scanner though) |
Hello!
You can determine the size of the parser by looking at the STATE_COUNT in
parser.c
. The current state count for this parser is 6740 which is extremely large. For comparison, the php parser state count is ~2700, and the phpdoc parser state count is ~339.The likely culprit here is the
_text
regex which results in a ton of fragments.The text was updated successfully, but these errors were encountered: