This article helps you diagnose and fix slow Vibgrate scans. It is for developers working in large repositories or monorepos where a scan takes longer than expected.
Start with scope
The fastest scan is one that analyzes only what matters. Exclude directories that do not need analysis, such as build output or vendored code:
vg scan --exclude dist
If your repository has many unrelated projects, scope the run to the directory you care about:
vg scan --cwd packages/app
Tune parallelism
Large repositories benefit from more concurrency. Increase parallel work with the concurrency or jobs controls:
vg scan --concurrency 8
On constrained CI runners, the opposite can help — lowering parallelism avoids resource contention.
Use the cache
The CLI caches work between runs. Avoid forcing a full recompute unless you are debugging a stale-result problem. If you previously added --no-cache, remove it for routine runs so subsequent scans reuse prior work.
Speed up code-map queries
If the slow part is vg ask rather than scanning, precompute the semantic index once so the first query is instant:
vg embed
After this, code-map queries run locally and offline.
Quiet output in CI
Verbose console output can add overhead and noise in pipelines. Reduce it:
vg scan --quiet
When it is the network
A pure local scan should not wait on the network. If a run stalls on network access, force local-only behavior to confirm:
vg scan --offline
If offline is fast, the delay was a network or proxy issue — see the proxy and offline configuration article.
Related
- Proxy and offline configuration
- Global flags reference
- The
vg scancommand page