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
Only compute Position if not already in state #9989
Conversation
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/10806/ |
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/10805/ |
Nice find @danez! I think with this change we might not need #9974. I did some simple profiling and it looks like with this change alone we get most of the perf benefits that would be gained from that PR:
So there is some additional benefit from adding #9974 to this, but this change alone is better than #9974 alone. Maybe I can trim that PR down a bit so we just take some of the simpler optimizations that don't add too much complexity. |
I think your PR is still very valuable and I don't see why we shouldn't bail out as soon as possible rather than try parsing and reverting state etc. |
Because of #9974 I was curious why throwing an exception is slow. So I did some investigation and my first guess was maybe we do something really slow when throwing. Turns out we do. 😫Every time we throw an exception we do calculate the line and column based on the current position (index) in the input string.
So I was curious if that can be improved and after looking through StackOverflow for a long time :P I couldn't get this algorithm (https://github.com/babel/babel/blob/master/packages/babel-parser/src/util/location.js#L41) any significant faster.
For a short time I thought I got it faster by using
substring() + split('\n')
instead of thefor + regex
, but the speed improvement was only because I basically removed support for line endings besides \n. After changing tosplit(regex)
it was slow again.I was thinking more about it and I realized that actually most errors are thrown right when encountered, means the state is currently pointing to the error position. In this case and even in the case when the error is reported for the last token, we can easily reuse the location that is already in the state. No need for calculation at all.
Before
After
So together with #9974 this should give a good boost for ts in certain situations
@matthewrobertson Can you check if that improves your reported case even further?