perf(linter): reduce iterations when collecting directories for nested configs

[overlookmotel]

Small perf optimization.

Presumably all paths will usually have the same prefix e.g.:

• /Users/bozo/projects/best-project-ever
• /Users/bozo/projects/best-project-ever/src/components
• /Users/bozo/projects/best-project-ever/src/server

When finding directories to search for nested configs, stop walking up to parent directories when find a directory that's already in the HashSet. We know that dir's parent, grandparent, etc will already be in the set too, so no need to check them again.

[overlookmotel]

• perf(linter): reduce iterations when collecting directories for nested configs #12329 👈 (View in Graphite)
• 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.

[overlookmotel]

I assume this'd be an improvement, but we don't have benchmarks for oxlint in CI. @camc314 How do you normally test changes like this to make sure they do have the desired effect?

[overlookmotel]

@camc314 Just a nudge on this one. Only reason I questioned whether it'd be a perf improvement is because of the comments above the code this PR changes. But "logically" it seems quite obvious that avoiding pointlessly iterating more than you need to should be a gain.

[camchenry]

This looks correct to me, I don't believe this should result in any configuration differences. This will only break out of the loop if it's a path that we've already processed (and therefore already know its nearest config).

I ran a benchmark on this locally. I used the latest oxlint 1.9 and built this PR with cargo build -p oxlint --release and compared the two on my M1 laptop. The project used for testing is the https://github.com/microsoft/fluentui repository at b5fa2f0ae70bc472c0603a3927ac68e65b702525. My local copy replaces every .eslintrc file with an .oxlintrc.json file containing {}. In total, there are 260 .oxlintrc.json files at various levels of the hierarchy (according to find . | rg oxlintrc | wc -l), and there are about 14836 lintable JS/TS files. These were the results:

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
oxlint-dev . --silent	404.0 ± 22.8	375.0	463.5	1.00
oxlint . --silent	444.2 ± 22.7	415.4	497.4	1.10 ± 0.08

On average, this PR is 10% faster than the current oxlint 1.9.0 version on the fluentui project (with eslintrc files replaced with oxlintrc). The fact that the minimum times are significantly different also gives me some confidence that this really does significantly reduce the work that we have to do in large monorepos with nested configs.

[camchenry]

For comparison, I also tested on microsoft/vscode (without any changes, just using the code as-is) to see how it fairs on a project without any nested configs. The difference was not significant, depending on the order that I ran the benchmarks one or the other could be faster.

[overlookmotel]

@camchenry Thanks very much for delving into this. Holy smokes! It had never occurred to me that a project might have 260 config files, or that this change would have anything more than a microscopic perf benefit.

[overlookmotel]

Merge activity

• Jul 30, 10:05 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jul 30, 10:05 AM UTC: overlookmotel added this pull request to the Graphite merge queue.
• Jul 30, 10:13 AM UTC: Merged by the Graphite merge queue.