Latest Results
perf(browser-field): fast-reject non-matching keys before normalize (#1227)
## What
`PackageJson::resolve_browser_field`'s reverse lookup (`request = None`)
runs on **every candidate path** when `alias_fields` is configured (via
`load_browser_field_or_alias` โ `load_alias_or_file` โ `load_as_file`).
For each candidate it looped over **all** browser-field keys, doing:
- `dir.normalize_with(key)` โ a `PathBuf` allocation +
`std::path::Components` parse, and
- `joined == path` โ a component-wise path comparison.
Profiling the warm resolve hot path (macOS `sample`) showed
`std::path::Components` iteration at **~40% of self-time**, driven
mostly by this loop (the `browser-module` fixture has 15 browser keys,
and the lookup recurses through `require`).
## Change
`normalize_with` preserves a key's last `Normal` path component, so if
that component differs from the candidate path's file name, the join
cannot equal the path. Compare file names first (a cheap byte
comparison) and skip the allocation + component-wise comparison for the
common non-matching keys.
Keys whose last component is not a normal name (`.`, `..`) have no
`file_name` and fall through to the full comparison unchanged, so
behavior is preserved. Applied to both the `simd` (little-endian) and
`serde` (big-endian) implementations.
## Result
`resolver_memory/single-thread`: **41.4ยตs โ 28.4ยตs (โ31%)** (criterion,
same machine).
Allocation pressure on the hot path drops sharply (sampled
`malloc`/`free`/`memmove` roughly halve or better).
All existing tests pass (`cargo test`, incl. the browser-field suite);
`cargo clippy --all-features --all-targets -- --deny warnings` is clean;
`cargo check --target s390x-unknown-linux-gnu` (exercises the `serde`
path) is clean. perf(browser-field): fast-reject non-matching keys before normalize (#1227)
## What
`PackageJson::resolve_browser_field`'s reverse lookup (`request = None`) runs on **every candidate path** when `alias_fields` is configured (via `load_browser_field_or_alias` โ `load_alias_or_file` โ `load_as_file`). For each candidate it looped over **all** browser-field keys, doing:
- `dir.normalize_with(key)` โ a `PathBuf` allocation + `std::path::Components` parse, and
- `joined == path` โ a component-wise path comparison.
Profiling the warm resolve hot path (macOS `sample`) showed `std::path::Components` iteration at **~40% of self-time**, driven mostly by this loop (the `browser-module` fixture has 15 browser keys, and the lookup recurses through `require`).
## Change
`normalize_with` preserves a key's last `Normal` path component, so if that component differs from the candidate path's file name, the join cannot equal the path. Compare file names first (a cheap byte comparison) and skip the allocation + component-wise comparison for the common non-matching keys.
Keys whose last component is not a normal name (`.`, `..`) have no `file_name` and fall through to the full comparison unchanged, so behavior is preserved. Applied to both the `simd` (little-endian) and `serde` (big-endian) implementations.
## Result
`resolver_memory/single-thread`: **41.4ยตs โ 28.4ยตs (โ31%)** (criterion, same machine).
Allocation pressure on the hot path drops sharply (sampled `malloc`/`free`/`memmove` roughly halve or better).
All existing tests pass (`cargo test`, incl. the browser-field suite); `cargo clippy --all-features --all-targets -- --deny warnings` is clean; `cargo check --target s390x-unknown-linux-gnu` (exercises the `serde` path) is clean.perf-browser-field-fast-reject Latest Branches
0%
-5%
refactor-package-json-dedup +2%
release-plz-2026-06-18T23-48-37Z ยฉ 2026 CodSpeed Technology