perf: avoid rescanning relative base on macOS ARM64

[hyfdev]

Summary

• Skip the second normalization scan of base after the macOS ARM64 NEON relative path has already proved that it is an exact component-boundary prefix of target.
• Keep the existing slow path and Cow<Path> ownership behavior for dirty spellings.
• Record the proof, target scope, paired measurements, controls, code-size result, and allocation result.

The production change is limited to macOS ARM64 with NEON. Windows, Linux, macOS x86_64, and other targets retain the previous implementation. This adds no unsafe code, API, allocation, or benchmark case.

Why this is safe

In the changed branch, base is an exact component-boundary prefix of the trailing-separator-trimmed target. Every base component and separator is therefore present in target, so a clean target also proves that base is clean.

The existing exhaustive oracle checks all 224,676 pairs from 474 short absolute spellings against unconditional normalization, including the returned Cow variant. Separate multibyte UTF-8, invalid native encoding, borrowing, and NEON boundary tests also pass.

Performance

Baseline: 7123f3c
Host: Apple M3 Pro
Criterion: 150 samples, 2 s warm-up, 5 s measurement, isolated baseline and candidate target directories

Existing benchmark	Change
module_to_cwd, natural Cow	-9.4%
module_to_cwd, PathBuf	-9.5%
same_directory, natural Cow	-18.7%
same_directory, PathBuf	-18.6%
same_path, natural Cow	-25.1%
package-sideEffects descendant text, borrowed	-7.2%
package-sideEffects descendant text, forced owned	-7.1%

different_subtrees, which does not enter the changed branch, showed no regression. A strip_prefix success control moved by 2%-3% in opposite directions when the measurement order was reversed, so it is treated as host-order drift rather than a change.

Release LLVM IR shrinks from 16,777 lines / 431 copies to 16,775 / 431. The deterministic allocation snapshot is byte-for-byte identical to main.

The first Linux CodSpeed comparison exposed a source-location layout artifact: three added physical lines changed seven panic location constants, shifted unrelated linked benchmark layout, and reproduced the exact opposing to_slash/as_path figures previously reported on PR #47 even though Linux instruction sequences were unchanged. The final source keeps those non-target locations stable. Its optimized Linux x86_64 library IR is byte-for-byte identical to 7123f3c (matching SHA-256), while retaining the proof comment and macOS ARM64 implementation.

The hosted rerun at b6158da passed all eight Actions jobs but the external CodSpeed Analysis check repeated the exact same 401.7 ns -> 460 ns and 255.8 ns -> 226.7 ns pair and now warned that the runtime environments differ. Because main and head have identical Linux production expansion, optimized library IR, instruction disassembly, and text-section sizes, neither row is attributable to this PR's runtime algorithm. Memory results remain unchanged.

Validation

• cargo fmt --all -- --check
• cargo test --locked --workspace --all-features
• cargo clippy --locked --workspace --all-targets --all-features -- -D warnings
• RUSTDOCFLAGS="-D warnings" cargo doc --locked --workspace --all-features --no-deps
• default/all-feature exhaustive suffix, borrowing, and SIMD tests
• default/all-feature library checks for macOS x86_64, Linux x86_64, Windows GNU, and Windows MSVC
• deterministic cargo allocs comparison against a clean 7123f3c archive
• byte-identical optimized Linux x86_64 library IR comparison against 7123f3c
• two-round adversarial review; final round passed

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 226 untouched benchmarks
⏩ 38 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	owned_receiver/string_result	401.7 ns	460 ns	-12.68%
⚡	Simulation	string	255.8 ns	226.7 ns	+12.87%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing agent/relative-base-rescan (b6158da) with main (7123f3c)}

Footnotes

1. 38 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. ↩

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.