[upstream issue Ephemeral-AI-Lab#516] Sandbox backends: twelve-cell speed comparison, Docker vs the no-Docker VM route (sub-issue of Ephemeral-AI-Lab#512)

• Upstream: Sandbox backends: twelve-cell speed comparison, Docker vs the no-Docker VM route (sub-issue of #512) Ephemeral-AI-Lab/layerfs#516
• Type: issue
• State: OPEN
• Updated: 2026-10-30
• Upstream labels: -

Original body (excerpt)

Goal

Compare LayerFS's speed on the no-Docker VM route (Ephemeral-AI-Lab#512, design in PR Ephemeral-AI-Lab#515) with today's Docker route, using the twelve R7 cells (C01–C12) as the workload. Same bundle, same Sandbox image, same cell runner, and the same stand-in on every VM; only the platform changes.

Candidates

Not timed:

• Firecracker: here it can only run nested inside a Lima VM, where page faults cross two hypervisors, so its timings would describe the nesting. It stays a pass/fail check.
• Daytona open source: its sandboxes are privileged containers on Docker Desktop, so it would re-measure Docker Desktop.
• Hosted providers: they need accounts and run on other hardware.

The twelve cells

The bodies are exactly those in benchmark/cluster-two/cells/workloads.py at the parent of 196c714b0b, the commit that removed the harness on 2026-10-20. The last baseline is TIMING-BASELINE-20261010.md.

Method

• A new runner, not the old one. The old R7 runner is pinned to the 2026-10-09 source, its own runtime binary and Docker CLI calls, so reviving it would measure old code. A small runner runs the same twelve bodies through the current SDK (workspace.exec). Its numbers compare across the four candidates here, not with the 2026-10-10 baseline.

• Cache state, class B as before:

  • per cell, a fresh project and Store;
  • an untimed setup (the committed base for C09–C11);
  • one untimed identical run on an earlier mount, then its terminal unmount;
  • then a fresh mount for the timed run.

  Every phase pays for its own work, with no warm-cache credit beyond that declared state.

• One sample per cell per candidate. No reruns, no best-of. Failed and ineligible cells are kept.

• What is recorded per cell:

  • the command time on the Sandbox's own clock, and the workspace.exec wall on the SDK side;
  • mount, unmount and Commit times;
  • the verifier's result (files, sizes and contents as the cell expects);
  • the daemon's request and statement counts where the current telemetry exposes them;
  • the Store and overlay bytes.

• Pinned identities:

  • the sealed bundle build-linux-bb5f636… (source 7ab54bcf1a, hashes checked against its manifest);
  • Sandbox image sha256:afa1ef9c…;
  • the runner's and the stand-in's sha256;
  • each VM's kernel, vCPUs and memory;
  • Disposable/WAL/OFF; LAYERFS_CONSTRUCTION_WORKERS=1.

• Interference: sampling commands on this Mac take one host-wide lock, so no two candidates sample at once. The 1-minute load is recorded with every sample. Preparation on other candidates may overlap and is declared. The VMs get 4 vCPUs and 4 GiB each, so that three VMs and Docker Desktop fit in this Mac's 36 GB without swapping; Docker Desktop keeps its own 8 CPUs and 8 GB and is shared with idle containers, which is recorded.

Rules

• Each command is bounded at 2 minutes, and each test invocation at 120 s.
• One attempt per step.
• Disposable Stores only, never the owner's.
• Every VM, volume and image the run creates is removed afterwards.

Results

• 0 Docker Desktop
• 1 Microsandbox
• 2 Apple Container
• 3 Lima
• Comparison table, with the exact counts first and timings second

Sync note

这是只读镜像，不是上游仓库的替代。上游 issue/PR 仍是唯一真源；本镜像不复制评论、不复制代码分支。