How long does review and apply take?¶

Motivation¶

Stage takes less machine time for the complete workflow when retaining sparse changes in a large workspace; Git workflows are faster for small workspaces or prepared views. The complete workflow includes private-workspace creation, diff review, selective application and disposal. Human reading and decision time is unmeasured, so these results do not estimate human supervision savings.

Creating a fresh workspace, changing 20 of 10,000 files and retaining ten takes 141 ms with pVisor stage, 248 ms with Git worktree and 343 ms with btrfs reflink. Applying prepared changes alone takes 17 ms, 0.93 s and 14.26 s for 10, 1,000 and 10,000 small files, all above Git patches; at 100,000 files two clusters center at 109.73 s and 196.87 s. The complete workflow applies only ten files, so its 141 ms cannot estimate a full 10,000-file apply. On a prepared twenty-file view, review, application and disposal take 27.71 ms for stage and 4.69 ms for Git.

These numbers and conclusions remain the original historical cohorts; the new framework has no matching rerun. See measurement coverage.

Experiment design¶

Measure the machine time to create a view, review changes, apply selected paths and discard the rest as complete-workflow time. It represents the machine overhead of reviewing and landing changes. Shorter times allow more reviews and applications per hour.

pVisor stage, a detached Git worktree and a btrfs reflink copy use identical prepared repositories of 100 or 10,000 files. Each task changes twenty files, applies the first ten and discards the rest. Timing covers view creation, edits, content review, selective application and disposal; input preparation and resets are excluded. Each cell has thirty samples and three warmups, randomized with a fixed seed, warm caches, on CPUs 0–1.

Every sample passes full inventory and content checks: the original stays unchanged, a normal apply changes only the ten selected files, and a conflict case must refuse the whole batch while preserving host content. Failures are counted, never timed as zero. A separate prepared-view experiment measures review, apply and drop over twenty files, and an apply-scale experiment covers 10 to 100,000 files with SIGKILL and host-edit injections. The fixed editing task excludes inference, compilation and human reading, and is not a container, VM or security ranking.

Data and analysis¶

Complete task cost¶

Same host and batch, 2026-10-06; milliseconds, N=30 per cell. No cell meets the predefined separated-cluster rule.

For 10,000 files, the stage-minus-Git median difference is -107.27 ms, 95% CI [-109.02, -105.60]; against reflink it is -202.18 ms, 95% CI [-204.49, -199.81]. Intervals use 5,000 bootstrap resamples paired by randomized sampling round and support stage being faster in this condition. For 100 files, stage minus Git is +86.99 ms, 95% CI [+77.28, +87.57] and stage minus reflink is +85.36 ms, 95% CI [+75.45, +85.86]; native workflows are faster in that small-workspace condition.

Review cost with a prepared view¶

Separate matched controls measured on 2026-10-06: twenty small text files, ten applied and ten discarded, N=30 per cell, zero failures. Milliseconds. No cell triggers the split rule.

The stage-minus-Git total median difference is +23.02 ms, 95% CI [22.49, 23.49], using 5,000 bootstrap resamples paired by sampling round. Git is faster in this small prepared-view condition. Step medians do not sum to the workflow median; human reading is unmeasured. Stage provides execution boundaries, staging and review interfaces; this small-edit review workflow has no measured speed advantage.

Where the cost lies¶

Normal application with 10,000 files; P50 milliseconds, N=30 per cell. Step medians do not sum to the complete workflow median.

Stage still adds tool-execution and application costs, but creating its private view, reviewing the changeset and discarding it do not require processing all 10,000 files. Git/reflink whole-tree work outweighs stage's additional costs in this sparse-edit workflow. This supports choosing stage for frequently created large task workspaces; it does not establish faster individual reads, writes or compilation.

Cost of preserving a host conflict¶

One selected host file is changed before application. The complete workflow includes creation, execution, review, refusal and disposal. P50 milliseconds, N=30 per cell.

No participant study was conducted. Batch review and machine timing cannot be converted into human time savings.

Application and disposal by scale¶

Measured on 2026-10-06. Units: ms; each cell is P50 / reference P95, N=30, with zero failures.

Apply at 100,000 files is reported as two clusters. Units: s.

Across all 30 samples the observed range is 107.42–205.33 s, with a reference P95 of 203.99 s. Budget for both clusters rather than using the faster cluster alone. Timing data does not establish the cause of the two clusters.

What the Git patch baseline means¶

Median differences use 5,000 bootstrap resamples of paired rounds with a fixed seed. Units: ms; 30 pairs per row.

All three scales show higher pVisor latency. The separated distribution at 100,000 files is not summarized by a single median difference. Git patches also check patch context, but do not provide the same preimage checks, durable application ledger and interruption-recovery workflow. This comparison estimates waiting time for the same text updates; it does not claim identical transaction semantics.

Host edits during apply¶

The independent injection check uses 10,000 files and N=3, without pooling these checks with the timing samples above.

All three windows explicitly reject the conflict and retain the host edit, Prepared ledger and complete upper. Some files have already been applied before the conflict, so this does not mean whole-batch rollback, and does not cover every race between the final check and rename.

SIGKILL recovery¶

At 10,000 files, N=3 per requested state. All nine injections hit the requested durable state, and rerunning passes target and Committed-ledger checks, with no missed injection windows. Units: ms; only medians and observed ranges are reported.

Recovery waiting time depends on the work completed before interruption. This checks process SIGKILL rather than power loss or storage corruption; three observations do not establish tail latency or a reliability guarantee.

Scope¶

The data covers warm caches and small text files in one directory. It does not cover large binaries, all file types, symlinks and metadata combinations, or macOS. Full content validation ran during measurement; retained commands and ledgers were independently audited, but cleaned target directories cannot be reread byte for byte. Finite conflict injections do not prove detection of every concurrent edit.

Application-scale and recovery data¶

Local provenance records binary, source, harness and raw-report digests. Timing and concurrent checks use the same binary in separate cohorts. Complete CSV/JSON, raw commands, reports and audit records remain in their local cohorts or the documentation data archive.

Reproduction follows the comparison method and the runner manual.

Historical cohorts retain their pinned sources, artifacts and timing scope. See the benchmark registry for active experiments and preparation status.