oxc-project/oxc-resolver

oxc-resolver

Performance History

Latest Results

chore(bench): exclude non-deterministic multi-threaded benches from CodSpeed The pm/* and resolver_*[multi-thread] benchmarks fan resolution out across rayon worker threads. Rayon's thread count is the detected core count, which varies across GitHub ubuntu-latest runners, and work-stealing is non-deterministic — so under CodSpeed's single-core instrumentation the instruction count is flaky (CodSpeed flags "Different runtime environments detected"). Unrelated PRs showed +-3-12% swings on these (e.g. a tsconfig-only change "regressing" pm/npm-flat -7% while pm/yarn-isolated "improved" +12%). Gate the rayon fan-out out of the codspeed feature: drop the two resolver multi-thread variants (the single-thread variant is the deterministic signal) and resolve the pm workload sequentially. Both still run multi-threaded under local `cargo bench`. The single-thread / symlinks / tsconfig / deserialization benches are unchanged.

perf/codspeed-rm-flaky-benches

12 hours ago

perf(cache): byte-level fast path for normalize_with A Time Profiler run on a warm resolve loop showed ~13% of CPU in `CachedPath::normalize_with_impl` — `std::path::Components` parsing plus per-component `PathBuf::push` — driven mostly by `exports`-field targets like `./dist/index.js`. Add a byte-level fast path: when the subpath is a simple relative path (no `.`/`..`/empty segments), join base+subpath by appending bytes, skipping `Components` and the per-segment push. Anything needing real normalization falls back to the existing `Components` path. Gated off Windows (`/`->`\` separator normalization) and wasm (interior-NUL stripping), which keep the slow path. resolver_memory/single-thread: -4% to -5% (p=0.00). Profiler confirms PathBuf::push self-time 4.1%->0 and Components 23%->17%. All 315 tests pass.

perf/normalize-with-bytes

15 hours ago

chore: release v11.22.0

release-plz-2026-06-18T23-48-37Z

17 hours ago

perf(resolve): compute parent once in package.json scope walk (#1235) ## What `find_package_json_for_a_package` runs on **every bare-specifier resolve** (`import 'react'` etc.). Its `inside_node_modules` walk called `p.parent(&self.cache)` **twice per loop iteration**: ```rust // @scope skip check if let Some(parent) = p.parent(&self.cache) && parent.is_node_modules() && … { break; } … cp = p.parent(&self.cache); // walk up — same parent, recomputed ``` `CachedPath::parent()` does a `Weak::upgrade` + `Arc` clone — atomic refcount operations the compiler **can't** common-subexpression-eliminate (the atomics are observable side effects). So each node_modules level walked paid for two upgrades instead of one. Compute it once and reuse. ## Notes Within noise on the macro benchmarks (`resolver_memory` single- and multi-thread) — the walk is a small slice of resolve time and the `Weak` upgrades are L1-cached hits — so I'm not claiming a benchmark number. The justification is that it removes genuinely duplicated atomic work (strictly fewer ops, never more, and fewer refcount touches matter more under multi-thread contention) and reads cleaner. All 275 tests pass (`--all-features`); clippy clean. Behaviour is identical.

main

17 hours ago

perf(resolve): compute parent once in package.json scope walk `find_package_json_for_a_package` runs on every bare-specifier resolve and called `p.parent(&cache)` twice per loop iteration — once for the `@scope` skip check and once to advance the walk. `parent()` does a `Weak::upgrade` + `Arc` clone (atomic refcount ops the compiler can't CSE across the side effects), so compute it once and reuse it. Strictly fewer atomic ops per node_modules level walked; within noise on the macro benches (the walk is a small slice of resolve time and the upgrades are L1-cached hits), but it removes duplicated work and reads cleaner.

perf/dedup-parent-walk

17 hours ago

perf/dedup-parent-walk

17 hours ago

chore: release v11.22.0

release-plz-2026-06-18T23-48-37Z

17 hours ago

perf(specifier): SIMD fast-reject of specifiers without query/fragment (#1234) ## What `cargo asm` shows `Specifier::parse_query_fragment` scanning every specifier **byte-by-byte** through a stateful loop — tracking `query_start`, `fragment_start`, and `prev` (for escaped `#`) — to locate `?`/`#`. This runs on **every resolve**, but the vast majority of specifiers (`./components/Button`, `react`, `@scope/pkg`) contain neither character. Fast-reject the common case with `memchr2`: if the specifier carries no `?`/`#`, return the borrowed specifier immediately and skip the stateful loop (and its `prev`/`escaped_indexes` bookkeeping). When a `?`/`#` *is* present, the original loop runs unchanged. ## On the `memchr` dependency `memchr` is **already linked** — pulled in by `json-strip-comments` (tsconfig comment stripping) and `serde_json` (JSON parsing), both of which actively use it — so declaring it a direct dependency adds **zero binary size**; it just references already-present code. `cargo-shear` is clean (the dep is used). ## Results | version | `resolver_memory/single-thread` | | --- | --- | | original (stateful loop) | baseline | | scalar `any` fast-reject | ~0.5% faster | | **`memchr2` fast-reject** | **~1.2% faster** (−0.68% vs scalar, p=0.01) | In an isolated microbench over the resolver's representative specifier set, `memchr2` scans ~37% faster than a scalar loop *even on short inputs* — on aarch64 NEON is baseline (no runtime dispatch) and memchr has an optimized small-input path. All 315 tests pass (`--all-features`); clippy clean. Behaviour is identical — the no-`?`/`#` case already produced `(Borrowed(specifier), None, None)`.

main

17 hours ago

Latest Branches

+10%

chore(bench): exclude non-deterministic multi-threaded benches from CodSpeed#1237

12 hours ago

b2d10bd

perf/codspeed-rm-flaky-benches

+2%

perf(cache): byte-level fast path for normalize_with#1236

15 hours ago

7a5a0a3

perf/normalize-with-bytes

-5%

chore: release v11.22.0#1228

17 hours ago

b37ce3b

release-plz-2026-06-18T23-48-37Z

Home Terms Privacy Docs