Repository navigation
npm: marked workload (mdapp.ts) is superlinear — 10 docs 0.16s, 100 docs >5min, 300 docs >55min (node: ~1s for 300) #7692
Description
Summary
With #7689 fixed (PR #7691), the marked npm package now runs correctly under Perry — but the issue's full comparison workload cannot be run to completion because Perry's runtime scales severely superlinearly in the number of documents parsed.
gc-handoff/apps/mdapp/mdapp.ts (300 generated markdown docs through marked.parse, counting <h2> tags):
| docs | node | perry (perry-dev profile @ 94ad784 + #7691 fix) |
|---|---|---|
| 10 | ~0.1 s, 20105 60 |
0.16 s, 20105 60 (matches) |
| 100 | ~0.4 s | killed at 5 min, not finished |
| 300 | ~1 s, 612040 1800 |
killed at ~55 min, not finished |
10 → 100 docs is a >1800× wall-clock blowup for 10× the input. Per-doc input size is essentially constant, so something in the per-parse path is superlinear in cumulative work — a side table growing per allocation/registration with O(total) lookups, GC behavior, or similar. The process stays ~50% CPU-busy the whole time (computing, not blocked).
Caveats on the numbers: measured on a loaded dev machine with an opt-level=1 (perry-dev) runtime, so the absolute times overstate the constant factor — but not the growth curve. Worth re-measuring --release on the quiet bench host first to get a clean curve before digging.
Repro
cd gc-handoff/apps/mdapp
export PERRY_RUNTIME_DIR=<repo>/target/release
<repo>/target/release/perry mdapp.ts -o p_mdapp
time ./p_mdapp # does not finish in any reasonable time
# vs: edit the loop to `i < 10` — finishes instantly with output matching nodeContext
This is the axis of the scriptc comparison in #7689: scriptc --dynamic produces 612040 1800 through its embedded engine in seconds; Perry now computes correct results natively but cannot finish the workload. Correctness landed in #7691; this issue tracks the scaling defect.
Activity
proggeramlug commentedon Aug 10, 2026
Re-measured on
main@db44b31b7, as this issue asks (--releaseon a clean build, plus theperry-devarm the original numbers came from). The superlinearity is gone in both profiles, and the full 300-document workload now completes with output identical to node.--releaseperry-dev94ad78435+ #7691,perry-dev)Output at 300 docs is
612040 1800from--release, fromperry-dev, and fromnode --experimental-strip-types— the exact value this issue names as node's. At 100 docsperry-devprints202640 600, consistent with the same per-doc rate.The curve is now linear, not superlinear:
--releaseruns 0.09 / 0.17 / 0.36 s at 10 / 40 / 100 docs, i.e. ~3.6 ms per document flat, and 300 docs lands where extrapolation puts it. The >1800× blowup between 10 and 100 documents does not reproduce.Notes on method, since this issue was explicit about them:
PERRY_NO_AUTO_OPTIMIZE=1,PERRY_RUNTIME_DIRpinned at freshly built archives, mtimes verified. Theperry-devarm was rebuilt immediately before measuring because an unrelated A/B earlier in the session had left those archives built from a modified constant — worth stating, because that is exactly the stale-archive trap that makes an A/B vacuous.This was not fixed by anything targeted at it. 78+ commits separate
94ad78435from currentmain, a dozen of them in the collector — #7742's whole-block in-place promotion, #7733's yield-adaptive major pacing, #7690/#7721 restoring evacuation at precise safepoints — and the symptom described here (~50% CPU-busy, cost growing with cumulative rather than per-document work) is the shape those changes address.Perry is now 2.5× node on this workload at 300 documents rather than unable to finish it. Closing as no longer reproducing; the remaining constant-factor gap belongs to the ordinary benchmark ladder, not to a scaling defect.