fastvol vs vol-rs vs python volatility3: benchmark

Measured 2026-09-27 20:11–21:18 CDT on this machine (a desktop, not a dedicated server):

How it was measured

• Every run is one process (TOOL -q -o DIR -f IMAGE PLUGIN, output to a file), timed from start to exit; runs are sequential, never two at once.

• Figures are medians of each tool's runs: fastvol 5 runs, vol-rs 3, python 1 per plugin (2 per triage session). A median does not favour the tool with more runs the way a best-of does.

• Each tool has its own caches (python's and vol-rs's symbol files were provisioned once; nothing downloads during the runs). The cache states:

  • python: warm (ISFs and identifier cache present). A first-ever python run would also download and convert the PDB; that is not measured.
  • vol-rs cold / warm: its cache deleted before every run (except downloaded PDBs) / as the previous run left it.
  • fastvol cold: its whole cache deleted before every run (symbol tables, identifier index, automagic results, scan results).
  • fastvol steady: symbol caches warm, scan-result cache off: every scan is really done. This is the like-for-like comparison with python's warm runs.
  • fastvol warm: every cache warm, including the per-image scan cache: scan results are replayed, not recomputed. What a user sees when re-running a plugin, but not the same work as python.

• The images are in the page cache unless a table says evicted (dropped with posix_fadvise(DONTNEED), so they are read from the NVMe drive).

• python, run in parallel for part of the all-plugins rounds (to finish in minutes instead of hours): 15 windows plugins, 59 linux plugins ran 6 python processes at a time, each pinned to its own physical performance core, after that round's fastvol and vol-rs runs (never alongside them). Six control plugins timed both alone and in the pool took 2.1% less time (median) in the pool: running in parallel did not slow python down, the speedups are not inflated.

• vol-rs: 3 runs per state for the first 62 plugins, 1 run after the schedule was shortened (like python).

Triage session (the realistic case)

A first look at an image: the common plugins run one after another, as an analyst would. first = the tool's cache empty at the start (it fills as the session goes), second = the same session again. Python's caches are always warm.

Windows (12 plugins: info, pslist, pstree, psscan, cmdline, dlllist, netscan, modules, getsids, handles, filescan, hivelist)

Linux (10 plugins: pslist, pstree, psaux, bash, lsmod, sockstat, lsof, malfind, elfs, check_syscall)

Every plugin once: Windows 11, 77 plugins

Sums answer "how long to run every plugin once"; they are dominated by the few slowest plugins. The per-plugin speedups below them show the spread.

Output identical to python in every timed run: fastvol cold 76/77, steady 76/77, warm 76/77; vol-rs cold 59/77, warm 59/77. fastvol's differences: windows.windows.Windows (python iterates a set: its row order changes run to run).

Every plugin once: Linux 6.8, 59 plugins

Sums answer "how long to run every plugin once"; they are dominated by the few slowest plugins. The per-plugin speedups below them show the spread. On Linux python spends most of each run decompressing and parsing the kernel's symbol file (3.3 MB xz, 61.5 MB of JSON) (its median plugin takes 10.6 s); fastvol keeps a binary symbol table in its cache, which the steady and warm states use. fastvol cold rebuilds everything each run and is the comparison with no fastvol cache at all.

Output identical to python in every timed run: fastvol cold 59/59, steady 59/59, warm 59/59; vol-rs cold 45/59, warm 45/59.

Startup: windows.pslist.PsList

Per plugin (medians)

windows

linux

Raw data: raw/raw.jsonl (every run), raw/machine.json, results.tsv. Harness: bench/scripts/bench_local.py; this report: bench/scripts/bench_local_report.py.