Unboxed tokens #257
Open
Unboxed tokens #257
+600
−559
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kornelski
requested review from
jongiddy,
Noah-Kennedy,
orium,
scotchmist,
jasnell and
a team
as code owners
kornelski
force-pushed
the
unboxed-tokens
branch
3 times, most recently
from
f81165f to
ec78225
Compare
kornelski
force-pushed
the
unboxed-tokens
branch
from
ec78225 to
d773b99
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This may be easier to review this as individual commits, since big diffs are from splitting and renaming files.
This refactoring removes
TokenCapturerandTokenCapturerEvent, which enablesLexeme::to_tokento be inlined. This way theTokenisn't moved around as much, and it's not necessary to useBox<Token>.This allowed
TextDecoderto be simplified, and handle just the decoding, similar toTextEncoder. I've added a fast path for handling text chunks, with zero-copy for UTF-8 and ASCII. It could have been even faster, if it didn't keep the existing tricky behavior: #255.Overall, it makes most benchmarks 5-8% faster, with 25-40% faster on text-heavy documents.