Benchmarks

Atmos runs 2.1x to 17.2x faster than the reference engine on a first scan of the same code with the same rules. On every one of those scans Atmos follows untrusted data from the file where it enters to the file where the dangerous call sits, but the reference engine stops at the edge of each file. Pick a project and play the scan.

How the run was set up

Machine

c3-standard-8 cloud VM, Intel Xeon Platinum 8481C, 8 vCPUs, 31 GB of memory, Ubuntu 24.04, Linux 6.17

Engines

Atmos 0.1.0. Reference engine 1.29.0, with analysis across functions within a file turned on.

Rules

One public rule pack in the YAML rule format, the same files on both engines, minus every rule either engine refuses to load.

Projects

Public open source projects at a pinned commit, with dependencies and build output excluded on both sides.

Runs

One untimed warmup per engine, then 5 timed first scans and 3 timed rescans per engine per project.

Date

2026-09-06

How the numbers are produced

Both engines run inside the same session on the same machine, alternating, with the order flipped on every rep so neither engine always goes first. Every rep is timed by the operating system as wall clock time, and the number reported is the median of the timed reps, never the best run.

Every arm reads the same files from the operating system's file cache, so the comparison is compute, not disk. The reference engine runs with analysis across functions within a file turned on, because its default mode is weaker than that and would inflate the ratio.

The two engines also do different amounts of work on the same rules. Untrusted input enters in one file and the dangerous call may sit in another. Atmos follows that path across files on every scan and reports the whole path as one finding, but the reference engine follows a path only inside the file where it starts. The Atmos times on this page include that cross-file work.

Findings are counted as distinct combinations of rule, file and line, because the reference engine reports the same finding more than once when several paths reach it. Both engines scan exactly the same set of files, checked file by file from their own reports.

The reference engine runs with its default limits. On the two largest projects a few dozen files hit its time limit for one rule on one file, which shortens its wall time and moves its finding count by a handful between its own runs.

Results

Times are the median wall clock seconds of a first scan. Memory is the peak of the largest process during that scan. The projects are public open source projects that we do not name, because a benchmark that names the code it runs on turns into a claim about that project rather than about the engine.

Rescans

After the first scan, one line is appended to one source file and both engines scan the tree again. Atmos rechecks only what changed and reports the same findings as before the edit on every project, but the reference engine scans everything again.

See how rescans stay fast.

Reproduce the run

1. Clone the project at a fixed commit and remove dependencies and build output.
2. Put the same rule files in front of both engines and drop every rule either engine refuses to load.
3. On a machine running nothing else, run one untimed scan per engine, then alternate the timed scans and flip the order on every rep.
4. Take the median of at least five reps, and count findings as distinct rule, file and line.

What this does not measure

Speed, memory and finding counts only. This run is not a comparison of detection quality and does not establish that either engine is right about any individual finding.