There is no single right number. Run time depends on code size, dependency depth and call graph precision. More precise graphs take longer and use more memory, so teams usually run a fast analysis on pull requests and a deeper one nightly or at release. Measure on your own repository rather than trusting a headline figure.
What drives the time
The Wikipedia call graph entry notes that a more precise call graph approximates the real program better, at the cost of taking longer to compute and more memory to store. It also notes that the most precise form, a fully context-sensitive graph, is usually not computed statically for large programs because it would take too long.
Practical drivers:
- Lines of code and number of dependencies. More nodes and edges.
- Language features. Dynamic dispatch and function values need alias reasoning, which is costly.
- Precision settings. Deeper context tracking multiplies work.
- Caching. Reusing graphs of unchanged dependencies saves most of the time.
- Scope. Analysing only changed modules is faster than the whole monorepo.
Matching depth to the moment
| Moment | Goal | Suitable approach |
|---|---|---|
| Pull request | Fast feedback to the author | Incremental, lower precision, cached dependency graphs |
| Nightly | Fresh backlog ordering | Full run on main branch |
| Release | Evidence for what ships | Deepest run on the built artifact |
| New advisory | Quick answer for one CVE | Targeted query against an existing graph |
How to benchmark a tool fairly
- Pick three repositories: small, medium and your largest.
- Time a cold run and a warm run with caching.
- Record peak memory, since a run that exhausts a CI runner fails in practice.
- Time a run after a one-line change to see incremental behaviour.
- Note any timeouts and what the tool reports when it times out. It should say so, not return a partial result labelled complete.
Budgeting for CI
Choose a time budget for pull request checks that developers will tolerate, often a few minutes, and confirm that the analysis fits. If it does not, move the deep analysis out of the blocking path and keep a fast check in it. A check that is too slow gets disabled, which is worse than a lighter check that stays on.
A reporting detail that matters
A timed-out analysis must not turn into a clean result. Ask how the tool labels incomplete runs. Unknown is the correct label.
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan to see the output on your own repository.
Quick check
Should reachability block pull requests?
Only if it is fast and its results are trusted. Many teams make it advisory on pull requests and enforce at release.
What if the run times out?
The result should be marked incomplete or unknown, never clean.
Sources
Last reviewed: 19 October 2026.
