modes.md

Execution modes, measured

Regenerated by ./gradlew modeBenchmark. Never edit by hand.

Measured against tmux 3.7b, 20 rounds per scenario, on one machine at one moment. Read the shape, not the milliseconds.

Reading the hierarchy

mode	wall clock	commands dispatched	tmux processes
DIRECT	1300 ms	80	80
CONTROL	172 ms	80	1 client, reused
VIRTUAL	766 ms	80	80

Building a workspace

mode	wall clock	commands dispatched	tmux processes
DIRECT	2314 ms	108	108
CONTROL	317 ms	108	1 client, reused
VIRTUAL	1418 ms	108	108

Collapsing round trips

The same 20 windows, asked for three ways under each carrier. batch() and chain() are not modes: they compose with whichever one is in force.

carrier and strategy	wall clock	commands dispatched	tmux processes
DIRECT, one call at a time	2314 ms	108	108
DIRECT, batch()	279 ms	9	9
DIRECT, chain()	196 ms	9	9
CONTROL, one call at a time	317 ms	108	1 client, reused
CONTROL, batch()	110 ms	9	1 client, reused + 1
CONTROL, chain()	96 ms	9	1 client, reused + 1
VIRTUAL, one call at a time	1418 ms	108	108
VIRTUAL, batch()	170 ms	9	9
VIRTUAL, chain()	173 ms	9	9

A group is carried by a process even under CONTROL, because a control client frames one reply per command and a group would desynchronise the stream. The process column is counted, not assumed, so that shows up here.

The same query, every way

server.windows().stream().filter(Window_.name().startsWith("bench")), and what each mode answered:

mode	result
DIRECT	[bench-0, bench-1, bench-2]
CONTROL	[bench-0, bench-1, bench-2]
VIRTUAL	[bench-0, bench-1, bench-2]

Identical, which is the point: a mode changes the carrying and not the answer. ExecutionModeConformanceTest asserts that; this shows it.