perf(linter): avoid multiple to_string_lossy calls in loop

[overlookmotel]

Small optimization: Call to_string_lossy only once, rather than 3 times in a loop.

[overlookmotel]

• perf(linter): avoid multiple to_string_lossy calls in loop #17212 👈 (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.

[Copilot]

Pull request overview

This PR optimizes the performance of file filtering by eliminating redundant to_string_lossy() calls. Instead of converting the filename to a string up to 3 times within the iterator (once per pattern check), the conversion is now performed once before the loop.

Key changes:

• Extract to_string_lossy() call outside the .any() iterator to avoid repeated string conversions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[overlookmotel]

Just for fun, I tried a further optimization, but unclear if it's better or not. Current version is massive amount of code, but looks like it uses SIMD: https://godbolt.org/z/6dx1438Gv

[camc314]

I would hope the compiler just hoists it out of the loop? but i guess not

[camc314]

Merge activity

• Dec 21, 4:27 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Dec 21, 4:27 PM UTC: camc314 added this pull request to the Graphite merge queue.
• Dec 21, 4:33 PM UTC: Merged by the Graphite merge queue.

[overlookmotel]

I would hope the compiler just hoists it out of the loop? but i guess not

I doubt it. string_to_lossy is probably too complicated a function for compiler to reason about. It probably has to assume that it could return a different value each time it's called and therefore hoisting it out of the loop isn't a safe optimization. I could be wrong though.