Performance: profile and improve cold extraction on large repositories

[TristanKruse]

Context

During the 0.0.1 real-world audit, building a dependency graph for Rails (3,445 Ruby files) took approximately 29.7 seconds on Windows with an empty graph cache. A second rule against the cached graph took approximately 0.045 seconds, so cache reuse is already effective; the opportunity is the first extraction in a fresh process, especially in CI.

Goal

Measure the cold extraction pipeline and improve its time and memory use without weakening correctness or changing graph semantics.

Work

• Add a reproducible benchmark corpus or generator that is suitable for CI.
• Optionally record a non-blocking Rails measurement in the planned weekly real-world canary.
• Profile file enumeration, file reads, Prism parsing, import extraction, target resolution, and edge merging separately.
• Investigate indexed resolution, safe parallel parsing, and incremental or persisted file-level caching only after profiling identifies the dominant costs.
• Record peak memory as well as wall-clock time.

Acceptance criteria

• A documented command reproduces the cold and warm benchmarks.
• Benchmark output separates the important pipeline stages.
• An evidence-based performance target is recorded after the baseline is stable.
• Any optimization preserves all existing extraction, cache, Windows, and integration tests.
• The warm-cache behavior does not regress.
• CI uses generous/non-flaky thresholds; hosted-runner noise must not block ordinary development.

The external Rails repository was analyzed statically; none of its application code was executed.