How much startup waiting can on-demand image reads save for shell and NumPy tasks?¶

Conclusions¶

With Linux/KVM, prepared image services and warm host page caches in a local protocol simulation, the Ubuntu shell on pVisor lazy VM reaches the checked first output with a cold-client P50 of 183.7 ms; all 30 observations precede cold-client Docker. For a small Python/NumPy script, no cold-client Ready median difference is detected despite lower content transfer; warm-client Docker is faster.

Motivation¶

For short commands in disposable environments, downloading and unpacking the complete image can cost more than the task itself. Choosing on-demand reads requires distinguishing service preparation from client startup and checking whether the advantage persists when the image is cached.

Experiment design¶

Linux x86_64 / KVM, Fedora kernel 7.2.8-200.fc44.x86_64, Docker 29.7.2, overlayfs/containerd image store. ubuntu:latest is pinned to the same Ubuntu 26.04 amd64 manifest. Docker pulls the complete image from an open-source Distribution registry:3 mirror; pVisor reads files on demand through real pvisor-cache serve. This service is distinct from OpenSandbox's pvisor-daemon serve.

The Ubuntu shell cohort runs the same /bin/sh on both paths: read /etc/os-release, verify Ubuntu 26.04, print one correct marker and exit successfully. Ready measures CLI launch to observation of the complete marker; Completion ends at process exit and output-stream closure, including teardown. The workload represents initialization for short commands; full distribution boot, Agent CLI initialization and large tool tasks are unmeasured.

A separate Python/NumPy cohort uses the public amancevice/pandas:slim-3.0.5 image, pinned to amd64 digest sha256:9a3a94039175ac799ad33c1a207997994ff9b24814e06508dddfa259b1ed9159. Both paths run the same small script with Python 3.13.14 and NumPy 2.5.2; pandas is included but not imported. With -B -u, OMP_NUM_THREADS=1, MKL_NUM_THREADS=1, OPENBLAS_NUM_THREADS=1 and PYTHONHASHSEED=0, it checks both versions, creates x = np.arange(16, dtype=np.int64).reshape(4, 4), asserts np.square(x).sum() == 1240 and (x @ x.T).sum() == 3680, then prints one unique marker and exits with code 0. Ready therefore includes imports and numerical correctness checks, representing a small numerical-script environment rather than large computation. The CPU/memory budgets, loopback protocol and cache/sampling controls below also apply to NumPy. Formal NumPy sampling ran without concurrent tests, builds or kernel benchmarks. The two workload cohorts remain separate; comparisons between them do not establish causal effects of workload or implementation changes.

Thirty formal samples per path/cache state in each cohort, with randomized Docker/lazy order within each round and cold followed immediately by warm for each path. One initial preflight and three warmup rounds are excluded. Each launch uses a fresh container or VM, workspace and stage. Before cold Docker, only the benchmark image is removed, and complete retrieval of every blob is required. Lazy uses a fresh client cache per pair, reused for warm startup. Services and host page caches remain warm; cold host storage and fully cold Docker snapshotter state are not independently established.

Included samples do not establish independent resource enforcement or host-integrity verification. Results describe these complete startup configurations; actual WAN, concurrency, equal whole-system budgets, pure lazy-algorithm contributions and pure VMM contributions are unmeasured. Service preparation is recorded separately: cache imports the same digest from Docker Hub, since the OCI client requires trusted HTTPS and does not import from the insecure local registry.

Data and analysis¶

Ubuntu shell client startup waiting¶

Measured 2026-10-07, n=30 per cell, 120 valid samples, zero formal failures and zero speed-based exclusions. Unit ms; unsplit distributions report P50, separated distributions report cluster medians and sample proportions. P95 is reference-only.

Every cold lazy observation precedes cold Docker, so the direction does not depend on a single overall median. Most warm Docker observations have shorter waits, with a separate slower cluster. Completion shows that VM/Job teardown also belongs in short-task budgets. Clusters follow the existing descriptive rule; their causes are undetermined.

Resampling complete paired rounds 5,000 times gives 95% intervals for Docker minus lazy marginal overall median differences: 389.2–833.9 ms cold and −86.1 to −48.2 ms warm. These intervals do not represent the centers of Docker's individual clusters and do not establish a single speed multiplier or causal pure-lazy benefit.

Client content transfer¶

Unit bytes, n=30 per cell, identical counts within each condition; measured through Completion.

Docker's content column counts compressed OCI layers and config; lazy counts uncompressed file-read payload. The short shell needs only the shell, dynamic loader, libc and related files, making the lazy content payload 93.8% smaller than complete OCI blobs. This describes application payloads for two delivery formats; total network traffic reduction is unmeasured. Docker's response count excludes HTTP headers/TLS, while lazy includes protocol frames and metadata; both exclude TCP/IP. Warm lazy still requires ping/prepare requests.

Image-service preparation cost¶

Unit s, n=1 per operation, single observed values.

The 183.7 ms cold-client Ready excludes the 15.130 s initial cache preparation. Preparation paths and work differ, so no preparation-speed ranking or amortization break-even estimate is supplied.

Small Python/NumPy script¶

Measured 2026-10-07 in a separate cohort: 120 formal samples, n=30 per cell, zero formal failures and zero speed-based exclusions. Unit ms; all Ready and Completion distributions are unsplit under the publication rule, so report P50. P95 is reference-only.

Paired-round bootstrap (5,000 resamples) gives a Docker minus lazy marginal Ready median difference of −135.3 ms, 95% CI [−204.1, 176.7] ms, for cold clients. The interval crosses zero: no cold-Ready median difference is detected, so neither path is established as reliably faster. The warm difference is −399.7 ms, 95% CI [−408.0, −389.8] ms: Docker is faster.

Through Completion, cold content is 115,930,809 bytes for Docker versus 36,951,980 bytes for lazy, a 68.1% reduction; related response counts are 115,932,435 versus 37,153,682 bytes. Warm content is 0 bytes for both, with response counts 0 for Docker and 750 bytes for lazy. Counts are identical within each cell (n=30); the content/response definitions and network-overhead exclusions above apply. Reduced content does not establish reduced cold startup waiting for this script. Separate service preparation takes 33.944 s for Docker Hub → Distribution mirror and 46.189 s for Docker Hub → cache (n=1 each), excluded from client timing; these single observations do not support a preparation-speed ranking.

Downloads and sources¶

Startup and payload statistics CSV · Differences and preparation costs CSV · Artifact and experiment provenance CSV · Reproduction manual

NumPy startup and payload statistics CSV · NumPy differences and preparation costs CSV · NumPy artifact and experiment provenance CSV

NumPy and Ubuntu shell use the same preexisting launcher and embedded firmware. NumPy uses a separately built cache-service binary with Docker gzip-layer support; this comparison does not measure gains from implementation changes. Exact artifact hashes are retained separately in the provenance CSVs.

B-LAZY-STARTUP uses a pinned manifest, preexisting release static musl artifacts and embedded firmware. Build-time source relationships are unverified; the current source manifest does not prove the artifacts came from that checkout. Artifact hashes match after sampling. Raw samples, logs, Run Bundles, artifact copies and the frozen harness remain in local ignored .data/; CSVs retain cohort, conditions, statistical definitions and the original report digest. Samples are kept separate from prepared-environment startup.