Indexing measurements and how to read them

A large reference index makes the scale of the evidence concrete: thousands of source files and documents can contribute hundreds of thousands of symbols and millions of relationships. The measurements below describe retained runs from 1 November 2026. They are historical observations from earlier builds, not a benchmark of the current application.

The reference workload

• 2,157,061 source lines of code in 5,604 code files.

• 2,268 project documents and 18 contract files.

• 7,890 indexed entries in total; non-indexed files are excluded from that count.

Windows — historical run, 1 November 2026

A full rebuild under the Fast profile completed in 1,328.794 seconds, about 22 minutes 9 seconds. The resulting index contained 744,423 symbols and 2,169,191 relationships. A subsequent automatic update with no source changes took 15.830 seconds, reused 7,890 prior file certificates, and parsed and hashed zero files.

Recorded host context: Windows 11 Pro, AMD Ryzen 5 2400G, four physical cores and eight logical processors, approximately 16 GB of RAM, and a SATA SSD. The host record was captured earlier on the same machine; competing workload and cache state were not controlled for each run.

Ubuntu Linux — historical runs, 1 November 2026

The same-size reference workload produced 770,735 symbols and 2,373,825 relationships. Its initial index under Balanced took 1,078.365 seconds, about 17 minutes 58 seconds. A later full rebuild under Fast took 863.286 seconds, about 14 minutes 23 seconds. The two runs retained the same indexed revision.

Recorded host context: Intel Core i7-8550U, eight logical processors and approximately 7.5 GiB of physical RAM. This context comes from an earlier host record, not a contemporaneous per-run hardware or load measurement.

What can be concluded

• These runs demonstrate the recorded workload and results on those builds and machines. They do not set a supported size ceiling or prove complete runtime understanding.

• A no-change update reuses prior evidence. Its time is not a full rebuild time or a changed-file incremental time.

• Windows and Ubuntu used different product versions and produced different graph totals. Do not combine one run’s counts with another run’s timing.

• The initial Balanced index and later Fast rebuild were not a controlled mode-only comparison. Their order and cache conditions differed.

• These historical runs do not establish current large-workspace performance, a universal speedup, migration-time savings or a per-run whole-process RAM peak.

Measure your own project consistently

• Record the Explorer version, operating system, CPU, RAM, storage, resource profile and source revision.

• Distinguish initial indexing, a full rebuild, a changed-file update and a no-change update.

• Use the same timing boundary and note competing work, cache conditions and repeated runs.

• Keep successful publication, source counts and any diagnostics with the result. Memory accounting is not the same as total process RAM.

• How resource profiles work

• Project indexing and updates

• Revision and currentness checks