-
Notifications
You must be signed in to change notification settings - Fork 65
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
Performance javascript grammar #409
Comments
Can you isolate this to a small grammar input that shows the same behavior? These sorts of things are sometimes ReDoS-style issues. |
Yes that might be the case although is rather complex to reduce the grammar we have CallExpressions https://github.com/peggyjs/peggy/blob/main/examples/javascript.pegjs#L631MethodExpressions etc. Maybe creating a MultiCallExpression might be able to help. |
If you turn on tracing, you might see the problem, with the same piece of input being parsed a lot. |
@hildjj Fixed it on my end, but if anyone encounters this adding caching (or the lack of) was one of the culprits, it might have been on the migration from peg that the setting was removed. Thank you very much. |
Did it work better with caching on, or with caching off? We might not have quite enough thought given to how caching interacts with the newer features. |
Caching on, it made a huge difference. |
Nod. You should still take a look at your grammar for ReDoS-style issues then. Places where you have |
Hi,
I have been using a variant of the javascript grammar for a while, but I have found a performance issue with multiple calls in a single statement.
The example function is:
as you can see this is due to many inner calls, up to call6 the performance is around 1 second the it might be more than 2 seconds..
Do you have any ideas on how to improve this?
The text was updated successfully, but these errors were encountered: