Repository navigation
Open
Labels
agent:triagedbenchsocket-patch scan benchmark suitesocket-patch scan benchmark suiteenhancementNew feature or requestNew feature or requestpm:pipenvPipenvPipenvpriority:p3
Description
[agent] Bench: pipenv has been flagged slow in 3 consecutive benchmark runs (2026-10-07, 10-08, 10-09). Its hosted scan costs 2.2–2.8x the median ms per package across all package managers.
| run | main | pipenv/hosted median |
ms/pkg | x median ms/pkg |
|---|---|---|---|---|
| 2026-10-07 | 9c43dfc9 |
133.8 ms | 0.335 | 2.2x |
| 2026-10-08 | ea097142 |
105.3 ms | 0.263 | 2.2x |
| 2026-10-09 | f3c6313a |
181.4 ms | 0.454 | 2.6x (2.8x from the same-machine compare head samples) |
Fixture: 400 packages, 12 patched, Pipfile.lock spec 6, in-project .venv.
Hot spot (callgrind, pipenv/hosted, 2026-10-09, main f3c6313a)
patch::redirect::pipenv::entriesis 61% of all instructions (inclusive), of whichpipenv::propertiesis 40%.parse_pipfile_lock(the inventory) is another 17%.pipenv::rewrite(crates/socket-patch-core/src/patch/redirect/pipenv.rs, ~L188) callsplan(&text, dep, …)once per pypi override, andplan(~L297) re-tokenizes the whole, progressively rewrittenPipfile.lockwithentries(text)to find that one package. That makes the rewrite O(patches × lock size).lock_targets(~L169) also canonicalizes every entry name once per override.- Possible fix: tokenize the lock once, index the entries by canonical name, and apply the per-package edits from that index (offsets shift only after each edit, so apply them back to front), the way Fix per-patch Poetry/PDM lock re-parse (#760, #762) #877 batched the Poetry/PDM rewrite (poetry/pdm hosted dropped 44–46% after it).
- The same pattern was measured on 10-07 (69% inclusive), so this is a standing cost, not a regression.
Runner
4 vCPU, Intel(R) Xeon(R) Processor @ 2.80GHz (cloud sandbox). Absolute timings vary from runner to runner; the ratio to the cross-PM median is the signal.
Repro
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 '^pipenv/' -v
# profile: serve the fixture, then prefix the printed command's binary with
# valgrind --tool=callgrind
target/perf/socket-patch-bench serve pipenv/hosted --bin target/perf/socket-patchTracked in the ledger of #575 (standing slow-systems list).
Generated by Claude Code
Metadata
Metadata
Assignees
Labels
agent:triagedbenchsocket-patch scan benchmark suitesocket-patch scan benchmark suiteenhancementNew feature or requestNew feature or requestpm:pipenvPipenvPipenvpriority:p3
Activity
mikolalysenko commentedon Oct 9, 2026
[agent] Triage:
priority:p1(pipenv is in the PyPI family). This is a performance enhancement, not a correctness bug. No open or merged PR addresses it yet. It is the same per-override re-tokenize pattern that #877 removed for Poetry/PDM, so the fix is to batch theformats::pipenvrewrite the same way. That fix belongs with (or after) the in-flight Pipfile.lock splicer refactor in #1188, so it does not conflict with that branch.Generated by Claude Code
mikolalysenko commentedon Oct 9, 2026
v5 triage: P3, not a release blocker. The reported Pipenv scan is about 0.13 seconds for hundreds of packages. Drop P1 to P3: a relative benchmark ratio alone is not a v5 blocker.
This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX.