> NOTE: We are actively compiling benchmark stats on the latest `roar` version. [Contact us](mailto:info@treqs.ai) for more information.

This page reports performance characteristics for the parts of `roar` whose overhead users actually feel: the tracer backends, the S3 proxy, and the content-hashing pipeline. The point isn't a single benchmark headline, but to provide enough detail to predict overhead on your own workload and pick configurations that match your performance budget.

All benchmarks are reproducible. Setup notes per section.

## Tracers

How much wall-clock overhead each tracer backend adds on top of a baseline command. See [Tracers](/docs/tracers) for the backend mechanics and tradeoffs that explain *why* the numbers differ.

| Workload | Baseline | eBPF | preload | ptrace |
|---|---|---|---|---|
| `cat <small file>` | TODO | TODO (~?%) | TODO (~?%) | TODO (~?%) |
| `python -c "pass"` | TODO | TODO | TODO | TODO |
| `python train.py` (MNIST baseline) | TODO | TODO | TODO | TODO |
| `dd if=/dev/zero of=out bs=1M count=1024` | TODO | TODO | TODO | TODO |

Per-syscall overhead breakdown, per backend:

| Backend | Per-syscall overhead |
|---|---|
| eBPF | TODO (in-kernel filtering; cheapest) |
| preload | TODO (libc interposition; very cheap on dynamically-linked binaries) |
| ptrace | TODO (two context switches per syscall; meaningfully higher) |

**Setup**: TODO — hardware, kernel version, what's running, how many trials.

## Proxy

How much overhead the [S3 proxy](/docs/proxy) adds on top of direct-to-S3 traffic. The proxy stands between an AWS SDK client and S3, re-signs each request, and forwards the result. Measurements should isolate the proxy's own work from network round-trip variability.

| Operation | Direct-to-S3 | Through proxy | Overhead |
|---|---|---|---|
| `GetObject` (1 KB) | TODO | TODO | TODO |
| `GetObject` (1 MB) | TODO | TODO | TODO |
| `GetObject` (100 MB) | TODO | TODO | TODO |
| `PutObject` (1 MB) | TODO | TODO | TODO |
| Multipart upload (1 GB, 8 MB parts) | TODO | TODO | TODO |

Sustained throughput on bulk transfers:

| | Direct | Through proxy |
|---|---|---|
| Single-stream `GetObject` | TODO MB/s | TODO MB/s |
| Multi-stream (16-way) `GetObject` | TODO MB/s | TODO MB/s |

**Setup**: TODO — bucket region vs. host region, network class, MinIO local vs. real-AWS, etc.

## Hashes

Throughput of the supported [hash algorithms](/docs/hashes) on the same hardware, measured on disk-backed reads.

| Algorithm | Throughput (single-threaded) | Throughput (SIMD / multi-threaded) |
|---|---|---|
| blake3 | TODO GB/s | TODO GB/s |
| sha256 | TODO GB/s | sha256 doesn't parallelize across one input |
| sha512 | TODO | sha512 doesn't parallelize across one input |
| md5 | TODO | md5 doesn't parallelize across one input |

How that translates to wall-clock cost for typical artifact sizes:

| File size | blake3 | sha256 |
|---|---|---|
| 10 MB | TODO | TODO |
| 100 MB | TODO | TODO |
| 1 GB | TODO | TODO |
| 10 GB | TODO | TODO |

**Setup**: TODO — CPU, disk class, whether the file is page-cached or cold, hashing library versions.

## Where to look next

- [Tracers](/docs/tracers) — backend tradeoffs that explain the tracer overhead numbers.
- [Proxy](/docs/proxy) — the S3 proxy's request-signing path that drives the overhead measurements.
- [Hashes](/docs/hashes) — why blake3 is default, and when sha256 is worth computing alongside.