Binary Manifest cache

Binary Manifest Cache for Faster Rebuilds

Summary

Introduce a binary cache for the parsed build manifest to significantly speed up subsequent builds when the manifest has not changed.

Motivation

Parsing the ASCII manifest is a significant bottleneck — the parse function accounts for a substantial share of total build time. Two main costs:

1. Binary format parsing is faster than ASCII parsing
2. Path operations like canonicalize() are expensive and currently re-executed on every parse — the binary cache stores the already-resolved paths

This especially helps with frequent rebuilds where the manifest is unchanged (e.g. incremental development cycles).

Proposed Behavior

• If no binary manifest exists: parse the ASCII manifest as usual, then write a binary cache file
• If a binary manifest exists: load the binary cache instead of the ASCII manifest
• If the generator produces a new manifest: fall back to ASCII parsing and regenerate the cache (binary cache becomes stale)

Activation

Opt-in via a new flag:

ninja --cache

Non-Goals

• No changes to build file syntax or semantics
• No changes to generators
• No new build features — strictly a performance optimization
• Cache is not intended to be portable across machines or architectures

Expected Impact

• Parse step faster on cache hit
• Significant speedup for frequent rebuilds when manifest is stable