Skip to content

Indexer has no memory/GC instrumentation; large-workspace runs are opaque to operators #1792

Description

@Widthdom

Summary

The indexer (FileIndexer.cs:12 and DbWriter pipeline) has no memory or GC instrumentation. On large workspaces (1M+ files, multi-GB total size), operators cannot tell whether memory growth is normal, whether a leak is present, or whether large-object-heap pressure is causing latency spikes. There are no GC.GetTotalMemory(false) snapshots between phases, no LOH allocation counters, no per-phase memory deltas.

Where

  • src/CodeIndex/Indexer/Scanning/FileIndexer.cs:12 (indexer entry)
  • src/CodeIndex/Database/DbWriter.cs (commit phase)
  • src/CodeIndex/Cli/JsonOutputContracts.cs (no memory fields)

Suggested approach

(1) Add a --memory-trace flag that captures GC.GetTotalMemory(false) and GC.GetTotalAllocatedBytes() at each phase boundary (scan, extract, write, finalize) and emits a MemoryTimeline block in the index JSON result. (2) Use GC.GetGCMemoryInfo() to surface fragmentation, generation sizes, and LOH usage. (3) Behind CDIDX_MEM_WARN_MB=1024, log a warning when working-set crosses the threshold. (4) Surface peak memory in status --json under index.peak_memory_mb after each index run completes. (5) Cover with a regression test that runs against a synthetic large workspace and asserts the timeline has populated entries. (6) Cross-link with C386 (per-query timing) — same instrumentation pattern, different signal.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions