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.
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
Reduce the number of allocations needed to find a specific child/sibling #119
Reduce the number of allocations needed to find a specific child/sibling #119
Changes from 12 commits
3d93945
fd63d90
05e47e9
9b96915
5d62e45
0dad088
94b039c
bff5da8
8ba46a7
2b94548
3f283c9
04e1a2a
39b5410
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Hm, why do we need to change anything here? I'd expect SyntaxElementChildren to remain exactly as they were
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.
Good question. I changed this so we could avoid creating
SyntaxElementChildren::next
when callingchildren().by_kind
. This actually makes a pretty significant impact - here's the DHAT output of the integrated completions benchmark without this optimization:And here's the DHAT output of the integrated completions benchmark after this optimization:
98 million blocks allocated (before this optimization) vs 86 million blocks allocated (after this optimization).
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.
Sounds odd to me that using
first_child_or_token_by_kind
with these extra changes is so much faster than seeking to the next sibling vianext_sibling_or_token_by_kind
, as both ways come down to iterating a slice no?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.
Hmm, my observation is that using
first_child_or_token_by_kind
allows us to jump to the first child/token node that matches a kind without needing to allocate any other nodes. Contrast this to usingfirst_child_or_token
followed bynext_sibling_or_token_by_kind
(if the first child doesn't match the kind), which can potentially allocate the first child before jumping to the desired node. I think its this allocation avoidance that explains the improvement in the DHAT outputs.