Slow scan: vlt hosted 2.6x median ms/pkg (vlt::partition_instances / split_dep_id per patch) #1570

[agent] Bench: vlt scans have been flagged slow by the daily socket-patch scan benchmark in 3 consecutive runs (2026-10-13, 2026-10-14, 2026-10-15). Both vlt scenarios are also over the 500 ms absolute limit.

Absolute timings come from different cloud runners, so read them as trend context only. Today's same-machine A/B shows no new day-over-day regression (vlt/hosted −4.4% [−6.9, +4.8]). Against 6fcc51b4 (7 days ago), vlt is 50% faster (1.00 s → 503 ms), but it is still the slowest npm-family scan per package by a wide margin. bun/pnpm are at 0.06 ms/pkg; vlt is at 0.34 ms/pkg.

Hot spot (callgrind, vlt/hosted, 1500 packages, 30 patched, head e76cb9b3)

patch::redirect::vlt::rewrite_vlt_lock accounts for 43% of instructions. Inside it:

• vlt::every_instance_pinned → vlt::partition_instances: 35% / 28% inclusive
• vendor::vlt_lock_text::split_dep_id: 20%, of which DepId::registry_identity is 16%, decode_segment 14% and is_npm_semver 13.5%
• hosted::vlt::plan → vlt_preflight::preflight_scope: 32%

The dep-id parsing (split_dep_id and its semver/identity checks) appears to run over every lock node once per patch or pin, rather than once per scan. Parsing the node keys once and indexing them by registry identity before the per-patch loop should remove most of this cost.

strace -c: 82% futex wait time (the worker pool idle while the main thread does the lock work), 20k statx, 9.8k openat.

Repro

export CARGO_PROFILE_PERF_INHERITS=release CARGO_PROFILE_PERF_LTO=thin CARGO_PROFILE_PERF_STRIP=none
cargo build --locked --profile perf -p socket-patch-cli -p socket-patch-bench
target/perf/socket-patch-bench run --bin target/perf/socket-patch -f '^vlt/' -v
target/perf/socket-patch-bench serve vlt/hosted   # then run the printed command under valgrind --tool=callgrind

Runner: 4 vCPU Intel(R) Xeon(R) Processor @ 2.80GHz (cloud sandbox). Tracked in #575.

Generated by Claude Code