Improve walk(…) performance
#15529
Merged
Improve walk(…) performance
#15529
Conversation
This file contains hidden or 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
Instead of creating a new path over and over again, we can instead push the node before the next loop starts, then pop it when we're done.
Instead of always calling `.splice()`, there are cases where if we replace a node with a single other note that we can replace it directly without using `splice(…)`.
Co-authored-by: Philipp Spiess <hello@philippspiess.com>
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 PR is a tiny improvement to the
walk(…)implementations, not a super bigdeal but thought about something and was pleasently surprised that it did have
an impact.
The idea is twofold:
pathto the current node. This re-uses the existingpatharray and pushes the current node before the recursive call and pops it afterwards. This way we don't need to allocate a new array for each recursive call. Testing this on Tailwind UI means ~14k fewer allocations..splice(…), we can directly update a single value in the array if we are replacing a node with another node.Testing on the Tailwind UI codebase, this results in:
