-
Notifications
You must be signed in to change notification settings - Fork 204
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
Custom Lexer Adapters #528
Comments
Performance seems virtually the same (±1%). So alles gute. 😀 |
Farther testing has shown a small performance regression of 3-4% for the full flow scenario (lexing + parsing). Need to update the benchmark to support a parser only scenario. |
benchmarking (on Chrome 59) only the parsing part showed a 12-13% regression for the JSON It may be that being extra generic is not worth it considering the performance regression. Currently there is only one productive relevant scenario that requires this adapter. |
Closing this. See above comments for details. |
Need to investigate this again as such an adapter may also be used to conserve memory |
Additional testing has showed a large strange regression in the CSS benchmark (x3/x4 slower). The other performance scenarios (JSON/ECMA5) showed a slight (3%) regression which is expected. I will once again close this, as at the end of the day this abstraction is just a convenience to help override Perhaps such unique flows (e.g token channels) should be provided as examples for extending the parser |
Refactoring the parser to multiple traits may make it easier to extract the Lexer Adapter API This should be evaluated again. |
Large API changes currently out of scope |
The text was updated successfully, but these errors were encountered: