dircue 1.3.1

dircue 1.3.1

Dircue 1.3.1 reduces allocation during import scanning and strengthens regression and installation checks. It adds no profiling module, changes no output schema, and preserves the existing command-line interface.

• JVM, .NET and JavaScript import scanning reuses cleared token arrays. Growth stops at the existing 16,384-token window; source references are cleared before reuse. The bound applies to each buffer, not to total process memory.
• CI enforces reviewed logical-work ceilings across all 16 local map fixtures. Changed fixture contents, missing or malformed statistics and exceeded budgets fail the gate. Wall time, heap and GC measurements remain descriptive.
• Seeded mixed-ecosystem tests check exact deep, Unicode and supported control-character source paths, worker counts, resource limits, relocation and documentation changes. Loose, packed, delta-repacked, shallow and linked-worktree Git layouts must produce the same entire map document at the same commit and tree. Three seeds run in full CI; twelve are available through the manual map workflow.
• Each publication runner checks a fresh exact-version uvx installation against the verified seven-wheel inventory. Recognized public-index propagation failures receive limited retries with retained diagnostics. Wrong versions, hash mismatches and unrecognized failures fail immediately; exhausted retries also fail the check. Ambient Python and index settings are removed, and transport retries require exact public hosts. Publication approval and provenance verification are unchanged.

Measured scope

Ten repetitions of the same isolated import benchmark on an Apple M1 Max with Go 1.26.6 gave the following medians. The correctness check warms the candidate's token pool before timing, so these measure repeated Java import parsing rather than first-file latency or an entire repository scan. The dense input reaches the existing token cutoff; its offered byte size is not reported as scanned-byte throughput.

Generated source	1.3.0 time	Candidate time	1.3.0 allocated bytes/op	Candidate allocated bytes/op
8 KiB	91.5 µs	44.0 µs	370,649	10,223
Dense 48 KiB	508.5 µs	211.0 µs	1,966,814	58,292

Whole-command measurements compared the published Darwin/arm64 1.3.0 binary with a candidate built using the same Go version and release flags. Both binaries reported version 1.3.0 for this comparison. Each workload used three warmups and twenty alternating pairs. Peak RSS was measured per process with macOS /usr/bin/time -l. Exit status, stdout and stderr matched byte-for-byte on every execution; source trees and Git metadata were hashed before and after.

Map workload	Median seconds, 1.3.0 → candidate	p95 seconds, 1.3.0 → candidate	Median peak RSS MiB, 1.3.0 → candidate
Spring Framework, Git	1.244 → 1.157	2.060 → 1.324	150.6 → 151.1
Spring Framework, directory	5.313 → 5.097	5.814 → 7.311	63.0 → 66.8
Roslyn, Git	6.115 → 6.039	6.465 → 6.987	304.1 → 310.6
uv, Git	0.665 → 0.680	0.716 → 0.764	97.7 → 97.4
microservices-demo, directory	0.200 → 0.198	0.209 → 0.215	45.5 → 45.8

These local warm-run measurements show a targeted allocation improvement and a roughly 7% median gain for Spring's Git map. Other whole-command differences are small or mixed; some tail times and peak-memory results are worse. They do not establish a universal speedup or lower process memory. Sampled allocated bytes in a separate Spring Git-map profile fell from about 1,177 to 582 MiB; allocation totals are not peak RSS.

A second twenty-pair run repeated the three noisier workloads after local test jobs finished. The original results above remain part of the evidence.

Repeated workload	Median seconds, 1.3.0 → candidate	p95 seconds, 1.3.0 → candidate	Median peak RSS MiB, 1.3.0 → candidate
Spring Framework, directory	5.523 → 5.411	6.665 → 5.772	62.9 → 68.0
Roslyn, Git	6.442 → 6.336	8.195 → 7.159	307.0 → 311.5
uv, Git	0.685 → 0.681	0.724 → 0.740	97.9 → 98.6

The earlier large tail-time increases did not repeat, while modest peak-memory increases did. Buffer reuse reduces allocation and trades some retained memory for that saving; neither run demonstrates a general wall-time improvement across these three workloads.

Regression replay against the published 1.3.0 binary passed all 278 compatibility cases, plus exact language, default aggregate and map output on 29 pinned repositories. Local gates passed 164 fixture assertions, 185 bounded public-quality records, 14 metamorphic invariants and 90 robustness variants. The seven-repository golden scores retain four relationship misses and eleven conservative coverage misses; these known limits are unchanged.

The fresh review adds literal token oracles and exact cutoff tests, requires generated manifests to belong to their distinct expected components, and validates every budget entry before execution using integer ceiling arithmetic. Verification commands clean up ordinary process groups on timeout and retain partial diagnostics, including incomplete UTF-8. Windows process-tree cleanup is best effort if the parent has already exited; deliberately detached processes require host containment. PyPI retry classification uses merged uv/executable stderr signatures, so it is a conservative heuristic rather than proof that execution never began. Any executable stdout remains fatal on a failed attempt.

The benchmark guide documents reproduction, correctness gates and measurement limits. The committed import-workload manifest pins all four repository revisions. Timing evidence is descriptive; no hosted-runner wall-time threshold or automatic baseline update is introduced. The generated assertions include deliberate output-corruption probes, which are not an independent accuracy estimate or a production mutation-coverage score.