perf(linter/only-used-in-recursion): improve skip_to_next_char slicing#17374
Merged
graphite-app[bot] merged 1 commit intomainfrom Dec 27, 2025
Conversation
Member
Author
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
github-actions
bot
added
A-linter
CodSpeed Performance ReportMerging #17374 will not alter performanceComparing Summary
Footnotes
|
graphite-app
bot
force-pushed
the
12-24-perf_linter_inline_is_function_node_into_run_functions
branch
2 times, most recently
from
571e6dc to
e188d8c
Compare
graphite-app
bot
force-pushed
the
12-25-perf_linter_only-used-in-recursion_improve_skip_to_next_char_slicing
branch
from
79e0eff to
43466f1
Compare
camchenry
force-pushed
the
12-24-perf_linter_inline_is_function_node_into_run_functions
branch
from
e188d8c to
23857c2
Compare
camchenry
force-pushed
the
12-25-perf_linter_only-used-in-recursion_improve_skip_to_next_char_slicing
branch
from
43466f1 to
75df67b
Compare
Contributor
Merge activity
|
…ing (#17374) This only really has an effect on the `react.development.js` benchmark, where I noticed we end up spending a lot of time in `skip_to_next_char`. Instead of iterating over the entire source, we slice from the start index and use `char_indices` from there. The start index _should_ always be at a char boundary, so there shouldn't be any risk of UTF-8 issues at slicing in middle of a character. I also took the opportunity to improve how trailing commas are handled and make the fix a little bit better and add another test case. <img width="730" height="441" alt="image" src="https://github.com/user-attachments/assets/680c5cfe-7cf1-4760-926f-fb2a1dc25a8f" />
graphite-app
bot
force-pushed
the
12-24-perf_linter_inline_is_function_node_into_run_functions
branch
from
23857c2 to
eecee5d
Compare
graphite-app
bot
force-pushed
the
12-25-perf_linter_only-used-in-recursion_improve_skip_to_next_char_slicing
branch
from
75df67b to
c27514c
Compare
Base automatically changed from
12-24-perf_linter_inline_is_function_node_into_run_functions
to
main
December 27, 2025 11:57
graphite-app
bot
deleted the
12-25-perf_linter_only-used-in-recursion_improve_skip_to_next_char_slicing
branch
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 only really has an effect on the
react.development.jsbenchmark, where I noticed we end up spending a lot of time inskip_to_next_char.Instead of iterating over the entire source, we slice from the start index and use
char_indicesfrom there. The start index should always be at a char boundary, so there shouldn't be any risk of UTF-8 issues at slicing in middle of a character.I also took the opportunity to improve how trailing commas are handled and make the fix a little bit better and add another test case.