perf(specifier): byte-level dispatch in require_without_parse

[stormslowly]

Why

Path::new(specifier).components().next() runs the full std::path::Components state machine — Windows-prefix detection, Component enum construction, UTF-8 boundary checks — on every resolve just to look at the first character. The separator and ./.. markers are always single-byte ASCII, so the dispatch can be done by direct byte inspection.

Base

This PR now targets bench/stable-short-specifier (#247), which splits the short specifier benches into their own [[bench]] binary. That gives CodSpeed a stable baseline for the per-case deltas so any change here reflects the parser, not binary-layout luck.

What

• SpecifierHead + classify_specifier_head in src/specifier.rs, with #[inline] so LTO inlines into require_without_parse (previous attempt without #[inline] showed cross-module-call regression on x86_64).
• require_without_parse matches on SpecifierHead instead of Components::next.
• Windows drive-letter / UNC specifiers still fall back to the std API.

Maintainability

A proptest property test (classify_matches_components_for_ascii, classify_matches_components_for_utf8) asserts that for any ASCII input on all platforms — and any UTF-8 input on Unix — classify_specifier_head agrees with Path::new(s).components().next()'s dispatch. Future changes that drift either side will fail the test.

Test plan

• cargo test --lib --features __internal_bench -- --skip 'tests::pnp::' — 142 / 142 pass
• cargo clippy --all-features -- -D warnings — clean
• CodSpeed run on top of the stable-bench base — isolates opt3's real per-case impact

[codspeed-hq]

Merging this PR will not alter performance

✅ 90 untouched benchmarks
⏩ 84 skipped benchmarks¹

---

_{Comparing perf/specifier-head-byte-dispatch (4742d9d) with bench/stable-short-specifier (68da90c)}

Footnotes

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

[stormslowly]

@codspeedbot explain this regression

[codspeed-hq]

@codspeedbot explain this regression

Based on my thorough analysis of the flamegraph data from both the HEAD and BASE runs, here's my explanation of this regression. This is an analysis-only response — no code changes are needed.

---

Summary: This is not a real code regression. It is a measurement artifact caused by the HEAD and BASE runs executing on different hardware.

Environment Mismatch

The CodSpeed report itself flagged this:

	BASE	HEAD
CPU	AMD EPYC 7763 64-Core	Intel Xeon Platinum 8370C

CodSpeed's simulation mode uses Valgrind/callgrind to model instruction and memory costs. The cache simulation model is sensitive to the underlying CPU's cache hierarchy (sizes, associativity, line sizes), so identical code can produce different simulated memory costs when run on different hardware.

Flamegraph Breakdown

Comparing Specifier::parse self time between the two runs:

Component	BASE	HEAD	Delta
Instructions	68.3 ns	68.3 ns	±0 (identical)
Caches	26.4 ns	27.8 ns	+1.4 ns
Memory	527.8 ns	555.6 ns	+27.8 ns
Self total	622.5 ns	651.7 ns	+29.2 ns

The instruction count — the component that directly reflects your code change — is exactly the same in both runs. The entire ~29 ns regression comes from the simulated memory access cost, which shifted due to the different CPU's cache model.

The overall benchmark delta (816.7 ns → 845.8 ns = +29.1 ns) lines up precisely with this memory simulation difference in Specifier::parse.

Conclusion

Your byte-level dispatch optimization is instruction-neutral on this specific benchmark case (rw/hash-only), which makes sense — this case hits the "normal module" fast path where classify_specifier_head replaces a Components::next() call that was already cheap for this input. The -3.45% regression is entirely an artifact of cross-CPU cache simulation differences and can be safely acknowledged/dismissed.

To get a clean apples-to-apples comparison, re-running CI so both HEAD and BASE land on the same hardware class would eliminate this noise.

Summary

• Warming up the performance wizard...
• Analyzing regression — Flamegraph comparison complete — regression explained
• Handling comment — Comment handling finished successfully

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}

[stormslowly]

It's not worth gaining little performance by making it a little unreadable