Slow scan: pdm hosted 3.6x median ms/pkg (per-patch pdm.lock re-parse)

[mikolalysenko]

[agent] Bench: pdm has been flagged slow in 3 consecutive benchmark runs (2026-10-02, 10-03, 10-04). Its hosted scan costs about 3.6x the median ms per package across all package managers.

run	pdm/hosted median	ms/pkg	x median ms/pkg	pdm/rescan median
2026-10-02	180.4 ms	0.451	3.5x	160.7 ms
2026-10-03	180.5 ms	0.451	3.5x	164.8 ms
2026-10-04	162.4 ms	0.406	3.6x	159.9 ms

Fixture: 400 packages, 12 patched.

Hot spot (callgrind, pdm/hosted, 2026-10-04)

• patch::redirect::pdm::rewrite → utils::pdm_lock::rewrite_pdm_lock_in: 77% of all instructions.
• Same shape as Poetry: PdmLockParse is reused only while doc.raw() == text (utils/pdm_lock.rs ~L225). Each dep's rewrite produces new text, so every following dep re-parses and re-serializes the whole pdm.lock. Cost is O(patches × lock size).
• Possible fix: apply all deps' mutations to one parsed document and serialize once. This could share a fix with the Poetry one (Slow scan: poetry hosted 4.5x median ms/pkg (per-patch poetry.lock re-parse) #760).
• Secondary: vex::discover::pypi_locks::extract (10.8%).

Runner

4 vCPU, Intel(R) Xeon(R) Processor @ 2.10GHz (cloud sandbox), main 045d7ec7. 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 '^pdm/' -v
# profile: serve the fixture, then prefix the printed command's binary with
#   valgrind --tool=callgrind
target/perf/socket-patch-bench serve pdm/hosted --bin target/perf/socket-patch

Tracked in the ledger of #575 (standing slow-systems list). This is a standing slowness report, not a regression: the cost has been flat since the suite started.

---

Generated by Claude Code

[mikolalysenko]

[agent] Shares root cause with #760: rewrite_poetry_lock_in and rewrite_pdm_lock_in each mutate, re-serialize and re-parse the whole lock once per patched dep (the *LockParse cache only saves the input parse), so hosted cost is O(patches × lock size). Will be fixed together. Both engines are being merged into one shared fragment-splice engine in open PR #703, so the batching fix should land on top of that.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (with #760; shared root cause: the shared Poetry/PDM fragment-splice engine renders and re-parses the whole lock once per patched dep). Branch: agent/fix-python-lock-batch-rewrite. Claim-ID: 2026-10-05T18:20:49Z-728c05

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #877

---

Generated by Claude Code