-
-
Notifications
You must be signed in to change notification settings - Fork 400
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
[Merged by Bors] - Interner support in the parser #1765
Conversation
I went through most files (skipped test files that looked like simple refactorings). Looks good to me so far. |
786ec51
to
f9e81a9
Compare
I got this to compile, but it seems I made a mistake somewhere, because it's failing the tests. |
All tests are now passing in my laptop, still Test262 results need to be checked, and of course, any performance issue. I didn't replace JsString with anything else, since the idea here was to use the interner only in the parsing phase. I added some static strings, the ones being used by us with |
828cf7b
to
e890a8e
Compare
Test262 conformance changesVM implementation
|
Codecov Report
@@ Coverage Diff @@
## main #1765 +/- ##
==========================================
- Coverage 55.72% 55.51% -0.21%
==========================================
Files 201 201
Lines 17336 17420 +84
==========================================
+ Hits 9660 9671 +11
- Misses 7676 7749 +73
Continue to review full report at Codecov.
|
Benchmarks
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally got around to review this. Looks really nice. I only found two things.
I noticed, that there are a lot of interner.resolve(s).expect("string disappeared")
calls. Do you think it would make sense to have a interner.resolve_expect(s)
helper?
I agree with raskad, a |
Makes sense, yes, especially now that we have our own interner. In any case, I still see a performance degradation, so maybe We should extend the usage in the compiler/vm and see how it goes |
I actually think the benchmark table is wrong.
But the table below seems to switch base and change values:
I also ran cargo bench locally for main and this branch and it showed a performance gain for almost all benchmarks. |
e890a8e
to
2ff513e
Compare
@Razican I rebased and implemented the fixes. Imo we can merge this into main. |
Did this add the |
I think the printing order is ok. This is the
|
Yep, that's what I meant, it doesn't preserve the original order. It's not critical, but might be something we want. In any case, I think this is good for now. We might want to optimize this by having a specific RegexLiteral node at some point, instead of converting it back to a string. |
db3c8c6
to
c4264c5
Compare
Benchmarks (properly switching the base):
Now things are looking much, much better |
c4264c5
to
94efa38
Compare
bors r+ |
This builds on top of #1758 to try to bring #1763 to life. Something that should probably be done here would be to convert `JsString` to a `Sym` internally. Then, further optimizations could be done adding common strings to a custom interner type (those that we know statically). This is definitely work in progress, but I would like to have feedback on the API, and feel free to contribute. Co-authored-by: raskad <32105367+raskad@users.noreply.github.com>
Pull request successfully merged into main. Build succeeded: |
This builds on top of #1758 to try to bring #1763 to life.
Something that should probably be done here would be to convert
JsString
to aSym
internally. Then, further optimizations could be done adding common strings to a custom interner type (those that we know statically).This is definitely work in progress, but I would like to have feedback on the API, and feel free to contribute.