# Performance
> How CGraph stays fast, and the levers you have — grounded in mechanics, not invented numbers.
[Source](https://open.nxtsoft.io/docs/cgraph/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](/docs/cgraph/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.

Use `cgraph-client status` to check the cache hit rate and confirm the graph is
current before a burst of queries.

## 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.

This page gives qualitative guidance from CGraph's documented mechanics. Specific
latency, throughput, and memory figures are not asserted here — they belong on
[Benchmarks](/docs/cgraph/benchmarks) with methodology, and are pending real
measurement.