LEARN MORE

Benchmarks

These are the numbers behind Kiri’s speed claims, with how each was measured and what to keep in mind. They come from bench/results.json in Kiri’s repository, which runkiri.com reads too. Every figure is either measured or a target, and this page says which.

How it was measured

The Mac figures come from one Apple Silicon Mac on macOS 27.0.1, last updated on 24 October 2026.

  • The test: create a container from alpine:latest, run true, wait for it to exit and be removed. 30 runs after 5 warm-up runs; the median (p50) and the 99th percentile (p99).
  • Two paths per engine: straight through the Docker Engine API on the engine’s socket (create, wait for removal, start), and through docker run --rm, which is what people type.
  • Same tools: all three engines were driven by the same docker CLI (29.7.2) and the same API calls, in one run, on the same Mac, once with the default bridge network and once with --network none.

Container lifecycle

docker run --rm alpine true, p50 of 30, default bridge network. Kiri's API figure is the engine's own time; most of its CLI figure is the docker CLI starting up.
The same test with --network none. Docker Desktop and OrbStack get faster without a network; Kiri stays about the same.

Every lifecycle figure, in milliseconds:

Engine Path Network p50 p99
Kiri Engine API bridge 2.55 4.72
Kiri docker CLI bridge 14.15 17.37
Docker Desktop Engine API bridge 213.4 774.1
Docker Desktop docker CLI bridge 243.3 350.8
OrbStack Engine API bridge 379.9 828.9
OrbStack docker CLI bridge 442.2 2383.2
Kiri Engine API none 2.68 5.79
Kiri docker CLI none 13.97 15.84
Docker Desktop Engine API none 109.6 127.4
Docker Desktop docker CLI none 111.4 125.4
OrbStack Engine API none 309.5 731.8
OrbStack docker CLI none 316.5 626.7

With Docker Desktop stopped, Kiri alone through the API with --network none took 1.26 ms (p50 of 50). Inside the VM, Kiri’s guest time splits into 0.39 ms for namespaces, mounts and the cgroup, and 1.41 ms for the process’s lifetime, including the bridged network setup and generated /etc files; that was measured while two other container VMs were busy.

Boot and sleep

The VM boots when Kiri first needs it and again each time it wakes from sleep. Cold boot to the agent being ready measured 112 ms (median of 5).

Cold boot of Kiri’s VM as the kernel was cut down: the stock arm64 defconfig, then allnoconfig with only what the VM has, then expedited RCU, then the virtio-pci reset patch. Each step keeps the one before; the last is today’s kernel.

Expedited RCU took the cgroup2 mount from 23 ms to 0.1 ms. The kernel image went from 32 MB to 10 MB.

Stage Measured
Virtualization framework configure and start (Apple’s helper process; outside Kiri) 95 ms
Guest kernel boot to PID 1 (680 ms with defconfig, 40 ms with allnoconfig) 8 ms
PID 1 to agent ready (15 ms before rcu_expedited) 0.4 ms
VM cold boot to agent ready, total 112 ms
Clean guest shutdown 2.2 ms
Host ↔ guest vsock round trip, p50 31 µs
Host ↔ guest vsock round trip, p99 62 µs

Memory and size

Resident memory of the engine. For OrbStack, dockerd plus containerd; for Kiri, the daemon on the Mac (9.0 MB footprint) plus the agent in the VM (0.69 MB). Docker Desktop hasn't been measured for these.

Kiri has no shim process: the agent supervises every container itself. OrbStack’s figure is 143 shims holding 1133 MB.

Measured
Daemon idle CPU 0.0 %
VM helper process footprint (Virtualization framework) 69 MB
Guest init binary: PID 1, agent and container runtime, with gzip, zstd and tar for layers 650 KB
kiri host binary, with TLS for pulls, the Docker API server and the window 2,165 KB
Guest kernel image (was 32 MB) 10,264 KB

Not yet measured

Some of Kiri’s other operations have only targets: budgets the design holds itself to, not results. OrbStack’s figures next to them are measured. Docker Desktop hasn’t been measured for these.

Operation Kiri target OrbStack measured
docker run -d (alpine, redis, python, nginx) 6 ms 205 ms
docker start of a pre-created container 4 ms 88 ms
docker unpause (cgroup freezer) 1 ms 23 ms

In the same set, OrbStack measured 325 ms (300 to 350) for docker run --rm alpine true and a 19 ms floor for one Docker CLI round trip.

Where a container start goes

The kernel work under a container start, measured inside a Linux 7.2 VM. Docker deletes the container’s veth before --rm returns, which is the single largest step.

The Linux building blocks of a container start, timed one at a time.

Windows and Linux

Kiri’s repository also keeps results for its other platforms, in bench/windows-2026-10-25.md and bench/ubuntu-2026-10-26.md.

Windows. One PC (Windows 11 Pro, AMD Ryzen AI MAX+ 395, 128 GB, WSL 2.6.3 with NAT networking), engines measured minutes apart with the same docker CLI 29.9.2 from PowerShell and the same images, warm. Docker Desktop 29.8.2 with default settings on its WSL2 backend; Kiri 0.1.0 as the Linux engine in Ubuntu 24.04, reached through \\.\pipe\kiri.

Windows, from PowerShell, medians of 20. OrbStack doesn't run on Windows.
From Windows Kiri Docker Desktop
docker exec … true, median of 20 57 ms 89 ms
200 MB container → host 255 MB/s 40 MB/s
Inside WSL: docker run --rm alpine true, median of 30 190 ms 669 ms

Inside WSL the Linux docker CLI’s own start dominates, so compare engines within a row, not across rows. Copying 200 MB into a container wasn’t comparable in that run, so it isn’t shown.

Linux. Kiri’s Linux engine against Docker Engine, Podman, nerdctl, Colima and Docker Desktop, in an Ubuntu 24.04 WSL2 distro on the same AMD machine. Not bare metal; the scripts are plain bash and rerun on a native host. Hyperfine medians, 30 runs.

Ubuntu 24.04 in WSL2, docker run --rm alpine true, median of 30. nerdctl went through its own CLI; the rest through the same docker CLI 29.8.2.

Kiri doesn’t win everything there. docker exec was 187 ms against 57 ms for nerdctl, and a published port moved 10.3 Gbit/s against 100.7 Gbit/s for Docker Engine, because Kiri relays published ports in user space. The full table is in the file.

Run them yourself

kiri bench runs the lifecycle test on your Mac against every engine whose socket it finds: Kiri, OrbStack (~/.orbstack/run/docker.sock) and Docker Desktop (~/.docker/run/docker.sock). Engines that aren’t running are skipped.

zsh
kiri bench --network bridge --runs 30
Flag Default
--runs N 50 Timed runs, after 5 warm-up runs.
--image IMAGE alpine:latest The image to run true in.
--network none|bridge none The network each container gets.
--only kiri|orbstack|docker all Measure one engine.

It prints p50, p99 and the mean for each engine and path, and how many times slower than Kiri each one is on the same path. Pull the image on each engine first.

kiri boot boots a VM of its own, times each stage, measures 1000 vsock round trips (--pings N changes that) and powers it off again.

© 2026 Kiri · runkiri.com