perf(linter): jest/prefer-hooks-in-order: rewrite rule to allocate less and iterate fewer times
#6030
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
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @camchenry and the rest of your teammates on |
Your org has enabled the Graphite merge queue for merging into mainAdd the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
CodSpeed Performance ReportMerging #6030 will not alter performanceComparing Summary
|
DonIsaac
approved these changes
Sep 24, 2024
Merge activity
|
…less and iterate fewer times (#6030) Profiling this in a single-threaded run showed this rule to be relatively slow compared to other rules: <img width="907" alt="image" src="https://github.com/user-attachments/assets/789cdc1f-d1ce-4d4a-bfa3-5882bd92cfc4"> The profile shows that a lot of time is spent doing pushes on `Vec`: <img width="896" alt="image" src="https://github.com/user-attachments/assets/cde361d7-091d-42db-abc2-76a0c8a7fa44"> I believe this is because we were essentially duplicating the entirety of `ctx.nodes()`, and then iterating over it again for the actual rule. I addressed this by: - We no longer store any nodes (we only store the previous hook span + order), which saves many allocations. - We only iterate over the nodes once and store the previous hook function in a per-scope hash map. This should be faster since we now only do `n` iterations, instead of `2n` iterations. Benchmarking on the `microsoft/vscode` repository shows that this is probably faster (by up to ~3%), and probably not any slower: <img width="992" alt="Screenshot 2024-09-24 at 12 06 32 PM" src="https://github.com/user-attachments/assets/ab916464-1b50-48e1-a65d-f9b3a4b4607d"> The snapshot change in this PR is due to slightly different ordering, I think, but it appears to be the same diagnostics overall.
DonIsaac
force-pushed
the
09-24-perf_linter_jest_prefer-hooks-in-order_rewrite_rule_to_allocate_less_and_iterate_fewer_times
branch
from
d18594c to
c16ae60
Compare
graphite-app
bot
deleted the
09-24-perf_linter_jest_prefer-hooks-in-order_rewrite_rule_to_allocate_less_and_iterate_fewer_times
branch
Boshen
added a commit
that referenced
this pull request
Sep 27, 2024
## [0.9.9] - 2024-09-27 ### Bug Fixes - bd8f786 linter: Rule and generic filters do not re-configure existing rules (#6087) (DonIsaac) - c5cdb4c linter: Disable all rules in a plugin when that plugin gets turned off (#6086) (DonIsaac) - 6c855af linter: Only write fix results if source code has changed (#6096) (DonIsaac) - 8759528 linter: Category filters not re-configuring already-enabled rules (#6085) (DonIsaac) - c2616f7 linter: Fix panic in fixer for `oxc/only-used-in-recursion` (#6070) (camc314) - 3da3845 linter: Malformed snippets in `eslint/for-direction` docs (#6060) (DonIsaac) - c047d42 linter: `no-useless-escape`: do not crash on backslash character (#6048) (camchenry) - 6f76ebe linter: Ignore invalid or partial disable directives (#6045) (camchenry) - 09a24cd linter: Fix false positives for generics in `no-unexpected-multiline` (#6039) (camchenry) - d05fd20 linter: Newline in type parameters causing false positive in `no-unexpected-multiline` (#6031) (DonIsaac) - 01b9c4b npm/oxlint: Make bin/oxc_language_server an executable (#6066) (Boshen) ### Performance - f8464a3 linter: `no-magic-numbers` remove redudant checks in `is_array_index` (#6033) (Alexander S.) - c16ae60 linter: `jest/prefer-hooks-in-order`: rewrite rule to allocate less and iterate fewer times (#6030) (camchenry) ### Documentation - a4fdf1b linter: Improve docs for promise rules (#6051) (dalaoshu) - 21cdb78 linter: Fix incorrect "bad" example in `only-used-in-recursion` (#6029) (Boshen) ### Refactor - 1f92d61 linter: `jest/prefer-hooks-in-order`: improve diagnostic messages (#6036) (camchenry) ### Testing - 55949eb linter: Add `OxlintRules::override_rules` tests (#6081) (DonIsaac) - 1a6923a linter: Add filter parsing test cases (#6080) (DonIsaac) - 58d333a linter: Add more test cases for disable directives (#6047) (camchenry) --------- Co-authored-by: Boshen <1430279+Boshen@users.noreply.github.com> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.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.
Profiling this in a single-threaded run showed this rule to be relatively slow compared to other rules:
The profile shows that a lot of time is spent doing pushes on
Vec:I believe this is because we were essentially duplicating the entirety of
ctx.nodes(), and then iterating over it again for the actual rule.I addressed this by:
niterations, instead of2niterations.Benchmarking on the
microsoft/vscoderepository shows that this is probably faster (by up to ~3%), and probably not any slower:The snapshot change in this PR is due to slightly different ordering, I think, but it appears to be the same diagnostics overall.