Summary
The status observer walks the project and, when a file has no indexed row to compare against, reads it through compute_checksum. On a brand-new or never-indexed project nothing is indexed, so _reuse_indexed_checksum misses on every file and the first bm status reads the entire project from disk.
Why it is avoidable
The answer for a never-indexed project is "not indexed". That is derivable from the walk alone — the checksums are computed to detect changes against indexed rows, and there are none to compare against. The work is spent producing information the caller cannot use.
Suggested: when a project has no indexed rows, report the unindexed state from the walk without checksumming. project.last_indexed_at (added in #1440) already distinguishes never-indexed from idle, so the condition is available without inferring it from counts.
Provenance and scope
Found while implementing #1414 (PR #1440), which fixed the closely related case: bm project add --no-wait was calling readiness and paying this same full scan, defeating the flag. That is fixed — --no-wait now prints the state rather than measuring it.
This one was left deliberately, because for bm status the scan is the observation the user asked for. It is an optimization rather than a defect, which is why it is filed separately rather than folded in.
Worth checking alongside
Whether the same reuse-miss cost appears on other first-run paths, and whether the walk could report a cheap "N files present, not yet indexed" without reading contents — that is the wording #1414 introduced for project add, and it would be consistent for status to answer the same way at the same cost.
Summary
The status observer walks the project and, when a file has no indexed row to compare against, reads it through
compute_checksum. On a brand-new or never-indexed project nothing is indexed, so_reuse_indexed_checksummisses on every file and the firstbm statusreads the entire project from disk.Why it is avoidable
The answer for a never-indexed project is "not indexed". That is derivable from the walk alone — the checksums are computed to detect changes against indexed rows, and there are none to compare against. The work is spent producing information the caller cannot use.
Suggested: when a project has no indexed rows, report the unindexed state from the walk without checksumming.
project.last_indexed_at(added in #1440) already distinguishes never-indexed from idle, so the condition is available without inferring it from counts.Provenance and scope
Found while implementing #1414 (PR #1440), which fixed the closely related case:
bm project add --no-waitwas calling readiness and paying this same full scan, defeating the flag. That is fixed —--no-waitnow prints the state rather than measuring it.This one was left deliberately, because for
bm statusthe scan is the observation the user asked for. It is an optimization rather than a defect, which is why it is filed separately rather than folded in.Worth checking alongside
Whether the same reuse-miss cost appears on other first-run paths, and whether the walk could report a cheap "N files present, not yet indexed" without reading contents — that is the wording #1414 introduced for
project add, and it would be consistent forstatusto answer the same way at the same cost.