perf(linter): move up rule retainment into initial collection to reduce allocation size

[camchenry]

In the current implementation, we collect all rules, and then remove rules that only run on specific node types and that have no relevant node types in the current file. This leads to a larger allocation size because we only remove the rules after we've already collected all of the rules.

This PR switches the order so that we filter out the rules before we actually collect them into a Vec. The downside of this is I can't see an easy way currently to make this work with the debug assertions we have for ensuring the runtime optimizations don't affect the output. The benefit of this is that the constant overhead for small files is much less, as shown by the benchmarks.

[codspeed-hq]

CodSpeed Performance Report

Merging #14822 will improve performances by 3.55%

_{Comparing 10-20-perf_linter_move_up_rule_retainment_into_initial_collection_to_reduce_allocation_size (0fc7f8b) with main (ee68089)}

Summary

⚡ 1 improvement
✅ 3 untouched
⏩ 33 skipped¹

Benchmarks breakdown

	Mode	Benchmark	BASE	HEAD	Change
⚡	Simulation	linter[RadixUIAdoptionSection.jsx]	729 µs	704 µs	+3.55%

Footnotes

1. 33 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[camchenry]

@camc314 I wanted to avoid doing this initially because I couldn't think of an easy way to make this work well with the runtime optimization toggling in debug. Maybe AI can come up with something better, but this appears to have quite a large effect for small files! Maybe we could run two sets of rules in debug and compare them?

[camchenry]

• perf(linter): allocate strings with some initial capacity #14842
• perf(linter): move up rule retainment into initial collection to reduce allocation size #14822 👈 (View in Graphite)
• perf(linter): id-length: reduce allocations and add more ASCII checks #14821
• perf(linter): use precomputed extension #14819
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

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.

[Copilot]

Pull Request Overview

This PR optimizes the linter's rule filtering by moving the retention logic earlier in the processing pipeline. Instead of collecting all rules first and then filtering them, rules are now filtered before collection, reducing memory allocation overhead for small files.

Key Changes:

• Moved AST node type checking into the initial filter predicate
• Eliminated the separate retain operation that occurred after rule collection
• Removed runtime optimization parameter from the execute_rules closure

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[camc314]

Merge activity

• Oct 29, 1:48 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Oct 29, 1:52 PM UTC: camc314 added this pull request to the Graphite merge queue.
• Oct 29, 2:01 PM UTC: Merged by the Graphite merge queue.