-
Notifications
You must be signed in to change notification settings - Fork 61
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
Closed
theo-lw
wants to merge
13
commits into
rust-analyzer:master
from
theo-lw:optimize-children-iteration
Closed
Changes from all commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
3d93945
Attempt to reduce the allocations needed to iterate through the child…
theo-lw fd63d90
Reduce allocations when looking through children with tokens, remove …
theo-lw 05e47e9
Run cargo fmt
theo-lw 9b96915
Moved 'a to children_with_tokens_matching
theo-lw 5d62e45
Expose the api as children().by_kind
theo-lw 0dad088
Remove unnecessary functions, fix off-by-one error
94b039c
Lazily create SyntaxNodeChildren::next and SyntaxElementChildren::nex…
bff5da8
Run cargo fmt
8ba46a7
Change Syntax*ChildrenMatching -> Syntax*ChildrenByKind
2b94548
Run cargo fmt
3f283c9
Change function names to use by_kind instead of matching. Use &dyn Fn…
04e1a2a
Expose SyntaxNodeChildrenByKind
39b5410
Changes per Veykril's comments
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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.
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.