Incremental indexing sounds like a simple promise: change one file, parse one file, finish quickly. The missing part is everything that follows parsing.
Look at the whole operation
Threadmark reuses unchanged per-file parses. Whole-graph resolution and JSON snapshot persistence still run during a refresh, however. The cache saves syntax work without removing the rest of the pipeline.
On the documented 10,000-file / 100,000-function fixture, v0.1.1 measured a 7.40-second new index, 3.52-second unchanged refresh and 4.60-second one-file update. Peak process working set reached 731 MiB. A warm, bounded graph query does not summarize those costs.
One improvement can expose the next cost
Version 0.1.1 avoids repeated symbol scans, moves reusable parsed files rather than cloning them, and skips writes for unchanged cache entries. It also uses a small revision table to invalidate cached graphs across database connections.
The same-host fixture improved unchanged refresh by about 43% against the documented v0.1.0 run. Query timings were slower in the newer run. Reporting both is more useful than keeping only the favourable number.
Write down the boundary of the measurement
These are single-run generated TypeScript fixtures with ten functions per file and no imports. The host was Windows 11 x64, an Intel Core i7-1365U with 16 GB RAM, using a Rust 1.98.1 release build. Filesystem caches were not flushed. A new Threadmark database is not a cold physical disk.
The next structural work is affected-subgraph resolution and more efficient persistence. Repeating a tiny warm query would not answer whether either change makes large refreshes better.
Based on performance methods and raw results. See the measurement table →