Performance

CGraph's performance story is architectural: extract once, keep warm, update incrementally, and spend context tokens only where they matter. This page is the practical guidance that follows from those mechanics. It gives you levers, not benchmark claims — for measured figures see Benchmarks.

Keep the graph warm

The single biggest lever is running the daemon. A one-shot cgraph run rebuilds the graph every time; graphd holds it in memory so queries don't re-scan. For any interactive or repeated use, start the daemon.

Let updates be incremental

While watching, the daemon folds ordinary edits into the graph within a couple of seconds rather than rebuilding. Two things follow:

• Prefer leaving the daemon watching during a work session.
• A large batch — a branch switch — collapses into one full rescan by design; this is cheaper than folding in a whole tree of changes, so expect a brief rebuild after big context switches rather than treating it as a stall.

Spend context tokens where they matter

For agent context, adaptive gather is the efficient default: it keeps the full 2-hop core and expands the third hop only along query-relevant nodes, then packs to your token budget. Provide a query (so the relevance gate is active) and a budget sized to the agent's window — this is what keeps context cost down without dropping the nodes that matter.

When to disable watching

If you don't want the daemon reacting to filesystem churn — for example in CI, or against a tree that's being rewritten by another process — run with --no-watch and drive updates explicitly with update operations. You trade automatic freshness for predictable, controlled rebuilds.

Determinism helps, too

Because extraction is deterministic, repeated runs over an unchanged tree produce the same graph, and the daemon can diff and fold changes rather than starting over. You benefit from this automatically; it's the reason incremental updates are possible at all.