zoo-bench - 2026-10-11 - AMD EPYC 7763 64-Core Processor

zoo-framework 0.6.0
benchmark

Same-caliber comparison against 5 baselines: apscheduler, asyncio_pool, bare_thread, process_pool, thread_pool. Every number was re-measured on this machine by zoo-bench and published per tier, including the tiers the framework under test loses.

raw data: results/zoo-framework-0.6.0/20261011T091515Z.json

zoo-bench report

Run environment

item	value
CPU model	AMD EPYC 7763 64-Core Processor
logical cores	4
platform	Linux-x86_64
operating system	Linux 6.17.0-1022-azure (#22-Ubuntu SMP Mon Jul 27 17:24:03 UTC 2026)
Python	CPython 3.13.16
interpreter	/opt/hostedtoolcache/Python/3.13.16/x64/bin/python
GIL	default
framework under test (distribution metadata)	0.6.0
framework under test (module __version__)	0.1.1-beta (footnote only, not the version criterion)
drive-surface generation of the framework under test	previous-generation drive surface (workers is a writable attribute; the completion signal comes from the framework's internal callback)
harness	zoo-bench 0.0.1 @ 9a42be24ac43f75e2e5d7b16434f91ba3d0717b6
command to reproduce	`zoo-bench run --framework zoo-framework==0.6.0`

data: Run environment

Run environment

Run environment (cont.)

dist_version (the distribution metadata) is the source of truth; module_version is only a footnote

data: Run environment

zoo-bench report

Workload

composition: one unit of work = JSON serialize + deserialize + string concatenation, repeated until the target duration is reached; the tiers are declared by body_tiers_us in matrix.yaml
the workload is a stand-in, not a real trace: its shape resembles business actions such as 'take a frame of data -> serialize -> parse -> transform strings', but this repository holds no real trace, so every conclusion is conditional on that

data: Workload

zoo-bench report

Measurement methodology

the body duration is instrumented within the same run: the body measures itself internally and reports back; framework overhead = end-to-end - it. No cross-run subtraction - two runs differ in state (caches, frequencies, scheduling noise), so subtracting introduces systematic bias.
warmups are excluded from statistics: each unit first runs 3 warmup rounds that are discarded, then only the following 30 measured rounds are counted; the sample count equals 'measured rounds x concurrency'.
absolute durations are not comparable across runs: they only show the order of magnitude; across versions/machines read the relative quantities within the same run (overhead share, multiples against the baselines), which are insensitive to overall speed.

data: Measurement methodology

zoo-bench report

Conclusion summary

Once the framework under test zoo runs a body of about 10000 microseconds or more, its framework overhead drops below 15% of end-to-end; below that tier, the main price of choosing it is the framework overhead itself.
At concurrency 1, within the measured tiers apscheduler is always faster than the framework under test - tiers like these are exactly the openly published unfavourable data of this report.
At concurrency 4, within the measured tiers apscheduler is always faster than the framework under test - tiers like these are exactly the openly published unfavourable data of this report.

data: Conclusion summary

Conclusion summary

Conclusion summary (cont.)

At concurrency 16, within the measured tiers apscheduler is always faster than the framework under test - tiers like these are exactly the openly published unfavourable data of this report.
At concurrency 64, within the measured tiers apscheduler is always faster than the framework under test - tiers like these are exactly the openly published unfavourable data of this report.
At concurrency 1, within the measured tiers asyncio_pool is always faster than the framework under test - tiers like these are exactly the openly published unfavourable data of this report.

data: Conclusion summary

Conclusion summary

the rest of this section's details are in the full report

For one conclusion per slide, only the first 2 slides of this section are shown; the remaining 10 slides of per-unit numbers, percentiles and raw samples sit in the same section of the full report, verbatim checkable.

full report: the "Conclusion summary" section of report.md in the same directory

Conclusion summary - framework overhead share

5.28%

Framework overhead share of zoo at body tier 10000 microseconds.
5 baselines are lower at this tier: apscheduler, asyncio_pool, bare_thread, process_pool, thread_pool.
same-tier comparison: apscheduler 3.41%, asyncio_pool 1.51%, bare_thread 1.31%, process_pool 3.30%, thread_pool 0.64%

data: zoo-bench "framework overhead share" at concurrency 1, body tier 10000 microseconds

Dimension: Latency percentiles and jitter

Latency percentiles and jitter at concurrency 1

concurrency 1 - end-to-end / concurrency

body tier 40 microseconds

zoo

606.25 microseconds

apscheduler

293.74 microseconds

asyncio_pool

145.49 microseconds

bare_thread

143.75 microseconds

process_pool

336.43 microseconds

thread_pool

74.84 microseconds

body tier 300 microseconds

zoo

867.95 microseconds

apscheduler

559.04 microseconds

asyncio_pool

389.99 microseconds

bare_thread

399.35 microseconds

process_pool

606.27 microseconds

thread_pool

338.26 microseconds

framework under testbaselinebar length = multiple relative to the framework under test; 1.0 is parity; longer is worse

data: zoo-bench "Latency percentiles and jitter" at concurrency 1 - per-unit numbers and percentiles are in the same section of report.md

Dimension: Latency percentiles and jitter

Latency percentiles and jitter at concurrency 1 (cont.)

concurrency 1 - end-to-end / concurrency

body tier 2700 microseconds

zoo

3.263 milliseconds

apscheduler

2.989 milliseconds

asyncio_pool

2.617 milliseconds

bare_thread

2.690 milliseconds

process_pool

3.015 milliseconds

thread_pool

2.669 milliseconds

body tier 10000 microseconds

zoo

10.505 milliseconds

apscheduler

9.889 milliseconds

asyncio_pool

9.708 milliseconds

bare_thread

9.552 milliseconds

process_pool

9.702 milliseconds

thread_pool

9.577 milliseconds

framework under testbaselinebar length = multiple relative to the framework under test; 1.0 is parity; longer is worse

data: zoo-bench "Latency percentiles and jitter" at concurrency 1 - per-unit numbers and percentiles are in the same section of report.md

zoo-bench report

Dimension: Latency percentiles and jitter

end-to-end / concurrency; percentiles and relative spread are given in the same table - a metric that only gives the median is not acceptable

concurrency	body tier (microseconds)	zoo	apscheduler	asyncio_pool	bare_thread	process_pool	thread_pool
1	40	606.25 microseconds	293.74 microseconds	145.49 microseconds	143.75 microseconds	336.43 microseconds	74.84 microseconds
1	300	867.95 microseconds	559.04 microseconds	389.99 microseconds	399.35 microseconds	606.27 microseconds	338.26 microseconds
1	2700	3.263 milliseconds	2.989 milliseconds	2.617 milliseconds	2.690 milliseconds	3.015 milliseconds	2.669 milliseconds
1	10000	10.505 milliseconds	9.889 milliseconds	9.708 milliseconds	9.552 milliseconds	9.702 milliseconds	9.577 milliseconds
4	40	611.17 microseconds	267.20 microseconds	153.05 microseconds	158.85 microseconds	192.86 microseconds	95.11 microseconds
4	300	866.98 microseconds	526.01 microseconds	428.07 microseconds	415.41 microseconds	283.82 microseconds	361.48 microseconds
4	2700	3.307 milliseconds	3.003 milliseconds	2.800 milliseconds	2.693 milliseconds	1.390 milliseconds	2.676 milliseconds
4	10000	10.700 milliseconds	10.132 milliseconds	9.695 milliseconds	9.872 milliseconds	4.608 milliseconds	9.867 milliseconds
16	40	610.25 microseconds	226.27 microseconds	138.37 microseconds	171.89 microseconds	161.53 microseconds	92.31 microseconds
16	300	878.71 microseconds	484.41 microseconds	395.42 microseconds	423.77 microseconds	278.33 microseconds	353.51 microseconds

data: Dimension: Latency percentiles and jitter

Dimension: Latency percentiles and jitter

Dimension: Latency percentiles and jitter (cont.)

concurrency	body tier (microseconds)	zoo	apscheduler	asyncio_pool	bare_thread	process_pool	thread_pool
16	2700	3.306 milliseconds	2.977 milliseconds	2.744 milliseconds	2.704 milliseconds	1.410 milliseconds	2.790 milliseconds
16	10000	10.596 milliseconds	10.332 milliseconds	9.964 milliseconds	9.972 milliseconds	4.636 milliseconds	10.146 milliseconds
64	40	565.92 microseconds	223.95 microseconds	120.73 microseconds	170.05 microseconds	196.54 microseconds	89.40 microseconds
64	300	842.59 microseconds	507.24 microseconds	371.91 microseconds	425.03 microseconds	300.97 microseconds	355.32 microseconds
64	2700	3.323 milliseconds	2.949 milliseconds	2.832 milliseconds	2.764 milliseconds	1.354 milliseconds	2.788 milliseconds
64	10000	10.636 milliseconds	10.585 milliseconds	10.189 milliseconds	9.526 milliseconds	4.629 milliseconds	10.289 milliseconds

per-unit values (percentiles, spread, raw per-round samples) are in 'Appendix: all values' at the end.

data: Dimension: Latency percentiles and jitter

Dimension: Framework overhead share

Framework overhead share at concurrency 1

concurrency 1 - framework overhead

body tier 40 microseconds

zoo

88.13%

apscheduler

80.50%

asyncio_pool

66.60%

bare_thread

64.52%

process_pool

83.87%

thread_pool

40.99%

body tier 300 microseconds

zoo

62.15%

apscheduler

46.08%

asyncio_pool

25.72%

bare_thread

26.40%

process_pool

49.32%

thread_pool

12.38%

framework under testbaselinebar length = multiple relative to the framework under test; 1.0 is parity; longer is worse

data: zoo-bench "Framework overhead share" at concurrency 1 - per-unit numbers and percentiles are in the same section of report.md

Dimension: Framework overhead share

Framework overhead share at concurrency 1 (cont.)

concurrency 1 - framework overhead

body tier 2700 microseconds

zoo

17.04%

apscheduler

8.91%

asyncio_pool

4.87%

bare_thread

4.18%

process_pool

11.36%

thread_pool

1.76%

body tier 10000 microseconds

zoo

5.28%

apscheduler

3.41%

asyncio_pool

1.51%

bare_thread

1.31%

process_pool

3.30%

thread_pool

0.64%

framework under testbaselinebar length = multiple relative to the framework under test; 1.0 is parity; longer is worse

data: zoo-bench "Framework overhead share" at concurrency 1 - per-unit numbers and percentiles are in the same section of report.md

zoo-bench report

Dimension: Framework overhead share

overhead = end-to-end / concurrency - the body duration measured within the same run (no cross-run subtraction). cells with -: that concurrency exceeds this machine's parallel capacity; the body's self-reported duration contains scheduling waits from oversubscription and is not comparable with the row's end-to-end per task, so no overhead figure is given (end-to-end and throughput live in their own dimensions)

concurrency	body tier (microseconds)	zoo	apscheduler	asyncio_pool	bare_thread	process_pool	thread_pool
1	40	88.13%	80.50%	66.60%	64.52%	83.87%	40.99%
1	300	62.15%	46.08%	25.72%	26.40%	49.32%	12.38%
1	2700	17.04%	8.91%	4.87%	4.18%	11.36%	1.76%
1	10000	5.28%	3.41%	1.51%	1.31%	3.30%	0.64%
4	40	89.54%	79.29%	64.75%	67.82%	51.69%	48.45%
4	300	62.78%	39.72%	24.92%	29.04%	-	14.55%

data: Dimension: Framework overhead share

Dimension: Framework overhead share

Dimension: Framework overhead share (cont.)

concurrency	body tier (microseconds)	zoo	apscheduler	asyncio_pool	bare_thread	process_pool	thread_pool
4	2700	19.63%	10.01%	4.93%	4.60%	-	2.23%
4	10000	-	-	-	-	-	-
16	40	-	-	-	-	-	-
16	300	-	-	-	-	-	-
16	2700	-	-	-	-	-	-
16	10000	-	-	-	-	-	-
64	40	-	-	-	-	-	-
64	300	-	-	-	-	-	-
64	2700	-	-	-	-	-	-
64	10000	-	-	-	-	-	-

per-unit values (percentiles, spread, raw per-round samples) are in 'Appendix: all values' at the end.

data: Dimension: Framework overhead share

Dimension: Throughput and concurrency scaling

Throughput and concurrency scaling at concurrency 1

concurrency 1 - throughput

body tier 40 microseconds

zoo

1,649 tasks/s

apscheduler

3,404 tasks/s

asyncio_pool

6,873 tasks/s

bare_thread

6,956 tasks/s

process_pool

2,972 tasks/s

thread_pool

13,363 tasks/s

body tier 300 microseconds

zoo

1,152 tasks/s

apscheduler

1,789 tasks/s

asyncio_pool

2,564 tasks/s

bare_thread

2,504 tasks/s

process_pool

1,649 tasks/s

thread_pool

2,956 tasks/s

framework under testbaselinebar length = multiple relative to the framework under test; 1.0 is parity; longer is worse

data: zoo-bench "Throughput and concurrency scaling" at concurrency 1 - per-unit numbers and percentiles are in the same section of report.md

Dimension: Throughput and concurrency scaling

Throughput and concurrency scaling at concurrency 1 (cont.)

concurrency 1 - throughput

body tier 2700 microseconds

zoo

306 tasks/s

apscheduler

335 tasks/s

asyncio_pool

382 tasks/s

bare_thread

372 tasks/s

process_pool

332 tasks/s

thread_pool

375 tasks/s

body tier 10000 microseconds

zoo

95 tasks/s

apscheduler

101 tasks/s

asyncio_pool

103 tasks/s

bare_thread

105 tasks/s

process_pool

103 tasks/s

thread_pool

104 tasks/s

framework under testbaselinebar length = multiple relative to the framework under test; 1.0 is parity; longer is worse

data: zoo-bench "Throughput and concurrency scaling" at concurrency 1 - per-unit numbers and percentiles are in the same section of report.md

zoo-bench report

Dimension: Throughput and concurrency scaling

throughput = concurrency / median end-to-end; whether it keeps rising with concurrency is the scaling behaviour

concurrency	body tier (microseconds)	zoo	apscheduler	asyncio_pool	bare_thread	process_pool	thread_pool
1	40	1649.5	3404.3	6873.2	6956.3	2972.4	13362.6
1	300	1152.1	1788.8	2564.2	2504.1	1649.4	2956.3
1	2700	306.5	334.5	382.1	371.7	331.7	374.6
1	10000	95.2	101.1	103.0	104.7	103.1	104.4
4	40	6544.9	14970.0	26136.1	25180.5	20740.7	42055.6
4	300	4613.7	7604.4	9344.3	9629.0	14093.4	11065.7
4	2700	1209.4	1331.9	1428.5	1485.5	2878.6	1494.9
4	10000	373.8	394.8	412.6	405.2	868.1	405.4
16	40	26218.8	70711.5	115629.2	93082.7	99052.0	173329.2
16	300	18208.4	33030.1	40462.9	37756.1	57486.6	45260.1
16	2700	4839.3	5375.2	5831.5	5917.6	11345.1	5735.0

data: Dimension: Throughput and concurrency scaling

Dimension: Throughput and concurrency scaling

Dimension: Throughput and concurrency scaling (cont.)

concurrency	body tier (microseconds)	zoo	apscheduler	asyncio_pool	bare_thread	process_pool	thread_pool
16	10000	1510.0	1548.6	1605.9	1604.5	3451.0	1577.0
64	40	113090.9	285777.7	530094.2	376362.9	325635.1	715882.7
64	300	75956.6	126173.2	172085.1	150577.9	212645.4	180117.2
64	2700	19258.5	21702.3	22599.7	23154.0	47269.4	22956.6
64	10000	6017.5	6046.2	6281.4	6718.2	13826.1	6220.2

per-unit values (percentiles, spread, raw per-round samples) are in 'Appendix: all values' at the end.

data: Dimension: Throughput and concurrency scaling

zoo-bench report

Dimension: Overhead attribution

scope: splits the per-task end-to-end into submit side / handoff / body / return and, at the same tier and concurrency, compares each segment against every baseline, answering 'which segment the excess falls on'. It is diagnostic, not the main evidence: it samples a small set of tiers, and does not compare total overhead against the baselines. A negative handoff is not an error: it means the submit call had not returned yet while the body was already running - schemes that count thread creation as submit side behave this way (measured: bare_thread handoff -343 microseconds). **The return segment includes waiting for th

e completion signal** (the last stretch before draining returns);

it shares the main measurement's scope

data: Dimension: Overhead attribution

Dimension: Overhead attribution

Dimension: Overhead attribution (cont.)

status: ok

this dimension is a diagnosis, not the main evidence: the sampled tiers and concurrencies are a fixed small batch, not the whole matrix. The concurrency ceiling is the machine's parallel capacity - beyond it, what is measured is contention;

sampled tiers (microseconds): 40, 10000; concurrency: [1, 4]; this machine's parallel capacity: 4

data: Dimension: Overhead attribution

Dimension: Overhead attribution

the rest of this section's details are in the full report

For one conclusion per slide, only the first 2 slides of this section are shown; the remaining 16 slides of per-unit numbers, percentiles and raw samples sit in the same section of the full report, verbatim checkable.

full report: the "Dimension: Overhead attribution" section of report.md in the same directory

zoo-bench report

Dimension: The cost of scheduling semantics

scope: this dimension uses an internal switch comparison (same workload, semantics all off vs. enabled one by one) and does not compare across schemes - a bare writeup has no counterpart for priority / timeout / retry, so it can only answer 'what is this framework's semantics worth', not 'how much more expensive than a bare writeup'

status: not_measured (the conclusion was reached on the 'previous' drive-surface generation installed during this measurement)

on the version under test, none of the enumerated semantic items is measurable: either its action is not implemented, or its layer cannot execute the reactor. Per design D7's escape hatch, such items are dropped instead of being replaced with an approximate status

data: Dimension: The cost of scheduling semantics

Dimension: The cost of scheduling semantics

Dimension: The cost of scheduling semantics (cont.)

semantics item	layer	how probed	measurable	evidence / reason
timeout	dispatch layer	behavioral probe (driven repeatedly through scheduling rounds; measures the moment the worker leaves the in-flight table)	no	the judgment exists but its action is not implemented: this probe drives through scheduling rounds and the probe worker declares a loop, so the rounds did run - a missing reap can only mean the judgment itself has no action. Enabling it would just add one subtraction and measure nothing of the semantics' cost
priority	event layer	structural probe (checks whether the symbols required for execution exist)	no	executing reactors on the event layer requires a perform symbol: EventWorker._execute calls reactor.perform (workers/event_worker.py), while EventReactor only defines execute (reactor/event_reactor.py) - a matched reactor would raise AttributeError at once; EventPriorityCalculator exists (fifo/node/event_fifo_node.py) but is not wired into the drain loop - 'sort by priority' in workers/event_worker.py is only a comment
retry	event layer	structural probe (checks whether the symbols required for execution exist)	no	executing reactors on the event layer requires a perform symbol: EventWorker._execute calls reactor.perform (workers/event_worker.py), while EventReactor only defines execute (reactor/event_reactor.py) - a matched reactor would raise AttributeError at once; retry_times defaults to 0, a clean off state, but its trigger is 'no reactor matched' - and the reactor path itself cannot execute

this conclusion was reached on the version under test and its coordinates hold for that version only; after appending a version to matrix.yaml, re-run this probe

data: Dimension: The cost of scheduling semantics

zoo-bench report

Dimension: Native task line: three execution forms of the same subject

scope: this line is measured on its own: it enters neither the main matrix's pivot tables nor its crossings, and its numbers must not be read against the baseline adapters listed there

verdict: not_applicable

the framework under test has no such capability (symbols not found: adaptive_params, dual_arm_worker, native_params, native_task_worker) - this line does not apply to this version, and that is not a failure

equivalence gate: not run (the probe did not reach it)

loaded task modbus_rtu.parse_response - Modbus RTU response-frame parsing: the input is a bare RTU ADU response frame (no transport framing), and the tier's frame bytes are its length

data: Dimension: Native task line: three execution forms of the same subject

Dimension: Native task line: three execution forms of the same subject

Dimension: Native task line: three execution forms of the same subject (cont.)

tiers R1, R8, R125 (frame bytes 7, 21, 255); concurrencies 1, 4, 16, 64; each cell runs 100 warm-up plus 100 measured rounds, one child process per concurrency (4 in all)

data: Dimension: Native task line: three execution forms of the same subject

zoo-bench report

tiers where the framework under test is faster

Tiers where the framework under test is ahead (the two sides differ by more than that tier's band). This comes from the same within-run comparison as the openly published unfavourable data - one side takes the faster tiers, the other the slower ones, so both cover the same ground and neither can pick its own tiers. This section being empty is not a failure: it should be empty when nothing is distinguishable or when the framework loses everywhere.

no tier within the measured set has the framework under test ahead.

data: tiers where the framework under test is faster

Openly published unfavourable data - summary

the framework under test is slower at 75 tiers, across 5 baselines.

apscheduler is faster at 13 tiers

worst 2.70x (concurrency 16 at 40 microseconds). All tiers: concurrency 1 at 40 microseconds, concurrency 1 at 300 microseconds, concurrency 1 at 2700 microseconds, concurrency 1 at 10000 microseconds, concurrency 4 at 40 microseconds, concurrency 4 at 300 microseconds, concurrency 4 at 10000 microseconds, concurrency 16 at 40 microseconds, concurrency 16 at 300 microseconds, concurrency 16 at 2700 microseconds, concurrency 64 at 40 microseconds, concurrency 64 at 300 microseconds, concurrency 64 at 2700 microseconds

asyncio_pool is faster at 16 tiers

worst 4.69x (concurrency 64 at 40 microseconds). All tiers: concurrency 1 at 40 microseconds, concurrency 1 at 300 microseconds, concurrency 1 at 2700 microseconds, concurrency 1 at 10000 microseconds, concurrency 4 at 40 microseconds, concurrency 4 at 300 microseconds, concurrency 4 at 2700 microseconds, concurrency 4 at 10000 microseconds, concurrency 16 at 40 microseconds, concurrency 16 at 300 microseconds, concurrency 16 at 2700 microseconds, concurrency 16 at 10000 microseconds, concurrency 64 at 40 microseconds, concurrency 64 at 300 microseconds, concurrency 64 at 2700 microseconds, concurrency 64 at 10000 microseconds

bare_thread is faster at 16 tiers

worst 4.22x (concurrency 1 at 40 microseconds). All tiers: concurrency 1 at 40 microseconds, concurrency 1 at 300 microseconds, concurrency 1 at 2700 microseconds, concurrency 1 at 10000 microseconds, concurrency 4 at 40 microseconds, concurrency 4 at 300 microseconds, concurrency 4 at 2700 microseconds, concurrency 4 at 10000 microseconds, concurrency 16 at 40 microseconds, concurrency 16 at 300 microseconds, concurrency 16 at 2700 microseconds, concurrency 16 at 10000 microseconds, concurrency 64 at 40 microseconds, concurrency 64 at 300 microseconds, concurrency 64 at 2700 microseconds, concurrency 64 at 10000 microseconds

process_pool is faster at 15 tiers

worst 3.78x (concurrency 16 at 40 microseconds). All tiers: concurrency 1 at 40 microseconds, concurrency 1 at 300 microseconds, concurrency 1 at 10000 microseconds, concurrency 4 at 40 microseconds, concurrency 4 at 300 microseconds, concurrency 4 at 2700 microseconds, concurrency 4 at 10000 microseconds, concurrency 16 at 40 microseconds, concurrency 16 at 300 microseconds, concurrency 16 at 2700 microseconds, concurrency 16 at 10000 microseconds, concurrency 64 at 40 microseconds, concurrency 64 at 300 microseconds, concurrency 64 at 2700 microseconds, concurrency 64 at 10000 microseconds

thread_pool is faster at 15 tiers

worst 8.10x (concurrency 1 at 40 microseconds). All tiers: concurrency 1 at 40 microseconds, concurrency 1 at 300 microseconds, concurrency 1 at 2700 microseconds, concurrency 1 at 10000 microseconds, concurrency 4 at 40 microseconds, concurrency 4 at 300 microseconds, concurrency 4 at 2700 microseconds, concurrency 16 at 40 microseconds, concurrency 16 at 300 microseconds, concurrency 16 at 2700 microseconds, concurrency 16 at 10000 microseconds, concurrency 64 at 40 microseconds, concurrency 64 at 300 microseconds, concurrency 64 at 2700 microseconds, concurrency 64 at 10000 microseconds

data: zoo-bench "published unfavorable data" - per-tier details follow on later slides and in report.md

zoo-bench report

Openly published unfavourable data

Tiers where the framework under test is behind (the two sides differ by more than that tier's band). A report missing this part is not acceptable - a report that only shows where it wins gives the reader every reason to distrust it. Tiers whose difference is smaller than the band are not here but in the 'no winner' section: that is the verdict's outcome, not a place to hide things.

baseline	concurrency	body tier (microseconds)	gap	median of the framework under test
apscheduler	1	40	apscheduler is 2.06x faster than zoo	606.25 microseconds
asyncio_pool	1	40	asyncio_pool is 4.17x faster than zoo	606.25 microseconds
bare_thread	1	40	bare_thread is 4.22x faster than zoo	606.25 microseconds
process_pool	1	40	process_pool is 1.80x faster than zoo	606.25 microseconds
thread_pool	1	40	thread_pool is 8.10x faster than zoo	606.25 microseconds
apscheduler	1	300	apscheduler is 1.55x faster than zoo	867.95 microseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baseline	concurrency	body tier (microseconds)	gap	median of the framework under test
asyncio_pool	1	300	asyncio_pool is 2.23x faster than zoo	867.95 microseconds
bare_thread	1	300	bare_thread is 2.17x faster than zoo	867.95 microseconds
process_pool	1	300	process_pool is 1.43x faster than zoo	867.95 microseconds
thread_pool	1	300	thread_pool is 2.57x faster than zoo	867.95 microseconds
apscheduler	1	2700	apscheduler is 1.09x faster than zoo	3.263 milliseconds
asyncio_pool	1	2700	asyncio_pool is 1.25x faster than zoo	3.263 milliseconds
bare_thread	1	2700	bare_thread is 1.21x faster than zoo	3.263 milliseconds
thread_pool	1	2700	thread_pool is 1.22x faster than zoo	3.263 milliseconds
apscheduler	1	10000	apscheduler is 1.06x faster than zoo	10.505 milliseconds
asyncio_pool	1	10000	asyncio_pool is 1.08x faster than zoo	10.505 milliseconds
bare_thread	1	10000	bare_thread is 1.10x faster than zoo	10.505 milliseconds
process_pool	1	10000	process_pool is 1.08x faster than zoo	10.505 milliseconds
thread_pool	1	10000	thread_pool is 1.10x faster than zoo	10.505 milliseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baseline	concurrency	body tier (microseconds)	gap	median of the framework under test
apscheduler	4	40	apscheduler is 2.29x faster than zoo	611.17 microseconds
asyncio_pool	4	40	asyncio_pool is 3.99x faster than zoo	611.17 microseconds
bare_thread	4	40	bare_thread is 3.85x faster than zoo	611.17 microseconds
process_pool	4	40	process_pool is 3.17x faster than zoo	611.17 microseconds
thread_pool	4	40	thread_pool is 6.43x faster than zoo	611.17 microseconds
apscheduler	4	300	apscheduler is 1.65x faster than zoo	866.98 microseconds
asyncio_pool	4	300	asyncio_pool is 2.03x faster than zoo	866.98 microseconds
bare_thread	4	300	bare_thread is 2.09x faster than zoo	866.98 microseconds
process_pool	4	300	process_pool is 3.05x faster than zoo	866.98 microseconds
thread_pool	4	300	thread_pool is 2.40x faster than zoo	866.98 microseconds
asyncio_pool	4	2700	asyncio_pool is 1.18x faster than zoo	3.307 milliseconds
bare_thread	4	2700	bare_thread is 1.23x faster than zoo	3.307 milliseconds
process_pool	4	2700	process_pool is 2.38x faster than zoo	3.307 milliseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baseline	concurrency	body tier (microseconds)	gap	median of the framework under test
thread_pool	4	2700	thread_pool is 1.24x faster than zoo	3.307 milliseconds
apscheduler	4	10000	apscheduler is 1.06x faster than zoo	10.700 milliseconds
asyncio_pool	4	10000	asyncio_pool is 1.10x faster than zoo	10.700 milliseconds
bare_thread	4	10000	bare_thread is 1.08x faster than zoo	10.700 milliseconds
process_pool	4	10000	process_pool is 2.32x faster than zoo	10.700 milliseconds
apscheduler	16	40	apscheduler is 2.70x faster than zoo	610.25 microseconds
asyncio_pool	16	40	asyncio_pool is 4.41x faster than zoo	610.25 microseconds
bare_thread	16	40	bare_thread is 3.55x faster than zoo	610.25 microseconds
process_pool	16	40	process_pool is 3.78x faster than zoo	610.25 microseconds
thread_pool	16	40	thread_pool is 6.61x faster than zoo	610.25 microseconds
apscheduler	16	300	apscheduler is 1.81x faster than zoo	878.71 microseconds
asyncio_pool	16	300	asyncio_pool is 2.22x faster than zoo	878.71 microseconds
bare_thread	16	300	bare_thread is 2.07x faster than zoo	878.71 microseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baseline	concurrency	body tier (microseconds)	gap	median of the framework under test
process_pool	16	300	process_pool is 3.16x faster than zoo	878.71 microseconds
thread_pool	16	300	thread_pool is 2.49x faster than zoo	878.71 microseconds
apscheduler	16	2700	apscheduler is 1.11x faster than zoo	3.306 milliseconds
asyncio_pool	16	2700	asyncio_pool is 1.21x faster than zoo	3.306 milliseconds
bare_thread	16	2700	bare_thread is 1.22x faster than zoo	3.306 milliseconds
process_pool	16	2700	process_pool is 2.34x faster than zoo	3.306 milliseconds
thread_pool	16	2700	thread_pool is 1.19x faster than zoo	3.306 milliseconds
asyncio_pool	16	10000	asyncio_pool is 1.06x faster than zoo	10.596 milliseconds
bare_thread	16	10000	bare_thread is 1.06x faster than zoo	10.596 milliseconds
process_pool	16	10000	process_pool is 2.29x faster than zoo	10.596 milliseconds
thread_pool	16	10000	thread_pool is 1.04x faster than zoo	10.596 milliseconds
apscheduler	64	40	apscheduler is 2.53x faster than zoo	565.92 microseconds
asyncio_pool	64	40	asyncio_pool is 4.69x faster than zoo	565.92 microseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baseline	concurrency	body tier (microseconds)	gap	median of the framework under test
bare_thread	64	40	bare_thread is 3.33x faster than zoo	565.92 microseconds
process_pool	64	40	process_pool is 2.88x faster than zoo	565.92 microseconds
thread_pool	64	40	thread_pool is 6.33x faster than zoo	565.92 microseconds
apscheduler	64	300	apscheduler is 1.66x faster than zoo	842.59 microseconds
asyncio_pool	64	300	asyncio_pool is 2.27x faster than zoo	842.59 microseconds
bare_thread	64	300	bare_thread is 1.98x faster than zoo	842.59 microseconds
process_pool	64	300	process_pool is 2.80x faster than zoo	842.59 microseconds
thread_pool	64	300	thread_pool is 2.37x faster than zoo	842.59 microseconds
apscheduler	64	2700	apscheduler is 1.13x faster than zoo	3.323 milliseconds
asyncio_pool	64	2700	asyncio_pool is 1.17x faster than zoo	3.323 milliseconds
bare_thread	64	2700	bare_thread is 1.20x faster than zoo	3.323 milliseconds
process_pool	64	2700	process_pool is 2.45x faster than zoo	3.323 milliseconds
thread_pool	64	2700	thread_pool is 1.19x faster than zoo	3.323 milliseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baseline	concurrency	body tier (microseconds)	gap	median of the framework under test
asyncio_pool	64	10000	asyncio_pool is 1.04x faster than zoo	10.636 milliseconds
bare_thread	64	10000	bare_thread is 1.12x faster than zoo	10.636 milliseconds
process_pool	64	10000	process_pool is 2.30x faster than zoo	10.636 milliseconds
thread_pool	64	10000	thread_pool is 1.03x faster than zoo	10.636 milliseconds

data: Openly published unfavourable data

zoo-bench report

tiers with no winner

Tiers where the two sides cannot be told apart: the difference is smaller than that tier's band. The band comes from the two sides' own across-round spread (stdev / median of the per-task medians) within the same run, so it varies with the sample and the reader can recompute it from the archived per-round samples. It also covers every measured tier and states a reason for each - this section is not a place to hide things: reporting noise-level differences as '1.00x faster' is.

criterion: band = the framework's own across-round relative spread plus the baseline's; a single side's across-round relative spread = stdev / median of that unit's per-round per-task medians

band this run: 1.6% to 41.9% (it varies with each tier's spread).

data: tiers with no winner

tiers with no winner

tiers with no winner (cont.)

baseline	concurrency	body tier (microseconds)	ratio	reason
process_pool	1	2700	0.92x	the two sides differ by 7.6%, less than the band of 21.2% - no winner
apscheduler	4	2700	0.91x	the two sides differ by 9.2%, less than the band of 9.6% - no winner
thread_pool	4	10000	0.92x	the two sides differ by 7.8%, less than the band of 9.2% - no winner
apscheduler	16	10000	0.98x	the two sides differ by 2.5%, less than the band of 5.1% - no winner
apscheduler	64	10000	1.00x	the two sides differ by 0.5%, less than the band of 4.1% - no winner

data: tiers with no winner

zoo-bench report

caliber limitations and sources of bias

measured layer: dispatch layer: drives BaseWaiter.execute_service() directly (thread-pool mode) instead of Master's full run loop - the latter's service loop fires once per second, which would lift the latency scale from microseconds to seconds. One scheduling round per submitted task, so that whole round's bookkeeping is charged to this single task; Master's usage serves several workers per round, which would spread that cost over tasks

data: caliber limitations and sources of bias

caliber limitations and sources of bias

caliber limitations and sources of bias (cont.)

scope note (apscheduler): APScheduler's scheduled-job model, including job registration and trigger-decision cost; the library swallows exceptions raised inside jobs, so this tier re-raises them during drain. Caliber note: the library offers no job-completion notification, so the completion signal comes from this tier's Condition, and the cost of one notification per task counts toward its end-to-end
scope note (asyncio_pool): the asyncio event loop dispatches synchronous bodies (equivalent to loop.run_in_executor), not native coroutine concurrency; the difference from a thread pool is the event loop's own cost

data: caliber limitations and sources of bias

caliber limitations and sources of bias

the rest of this section's details are in the full report

For one conclusion per slide, only the first 2 slides of this section are shown; the remaining 5 slides of per-unit numbers, percentiles and raw samples sit in the same section of the full report, verbatim checkable.

full report: the "caliber limitations and sources of bias" section of report.md in the same directory

zoo-bench report

bring your own baseline

the baselines of this harness are open: implement the four methods of zoo_bench.adapters.BaseAdapter (setup / submit / drain / teardown), register with zoo_bench.adapters.registry.register, or list your module path in extra_modules of matrix.yaml - no file in this repository needs to change. Your implementation goes through the same equivalence verification (submit N bodies, assert all ran and each exactly once);

failing it means the data is not trusted. We deliberately write this path into the report: a report written by the framework's own maintainer, measuring that framework, gives every reason to suspect a slowed baseline or a chosen caliber; letting anyone submit their own baseline is what makes this report challengeable and falsifiable.

data: bring your own baseline

zoo-bench report

self-check

overall measurement self-check: passed
process isolation: {'parent_pid': 2921, 'child_pids': [3381, 3384, 3387, 3391, 3394, 3400, 3406, 3412, 3418, 3436, 3454, 3472, 3490, 3546, 3603, 3661, 3729, 3731, 3733, 3735, 3737, 3742, 3747, 3752, 3758, 3775, 3792, 3809, 3828, 3887, 3947, 4010, 4079, 4113, 4147, 4181, 4215, 4348, 4482, 4615, 4748, 5277, 5806, 6335, 6865, 8979, 11092, 13205, 15321, 15325, 15329, 15333, 15337, 15344, 15351, 15358, 15365, 15385, 15404, 15423, 15442, 15509, 15576, 15643, 15712, 15714, 15716, 15718, 15720, 15725, 15730, 15735, 15744, 15761, 15778, 15796, 15813, 15869, 15926, 16009, 16084, 16086, 16088, 16090, 16092, 16097, 16102, 16107, 16112, 16129, 1
6146, 16163, 16182, 16247, 16312, 16378], 'all_distinct': True, 'none_equals_parent': True}

data: self-check

appendix

every slide can be checked verbatim in the full report

slides are compressed for one conclusion per page; only the layout is compressed, never the numbers.

per-unit details (percentiles, spread, raw samples per round): report.md in the same directory
figures (SVG and PNG): figures/ in the same directory; also report.pdf
raw archive: results/zoo-framework-0.6.0/20261011T091515Z.json
96 valid units in this run, 0 failed

the details run over a hundred rows; squeezing them into slides would strip readers of the means to verify.

zoo-framework 0.6.0benchmark

Run environment

Run environment (cont.)

Workload

Measurement methodology

Conclusion summary

Conclusion summary (cont.)

the rest of this section's details are in the full report

Latency percentiles and jitter at concurrency 1

Latency percentiles and jitter at concurrency 1 (cont.)

Dimension: Latency percentiles and jitter

Dimension: Latency percentiles and jitter (cont.)

Framework overhead share at concurrency 1

Framework overhead share at concurrency 1 (cont.)

Dimension: Framework overhead share

Dimension: Framework overhead share (cont.)

Throughput and concurrency scaling at concurrency 1

Throughput and concurrency scaling at concurrency 1 (cont.)

Dimension: Throughput and concurrency scaling

Dimension: Throughput and concurrency scaling (cont.)

Dimension: Overhead attribution

Dimension: Overhead attribution (cont.)

the rest of this section's details are in the full report

Dimension: The cost of scheduling semantics

Dimension: The cost of scheduling semantics (cont.)

Dimension: Native task line: three execution forms of the same subject

Dimension: Native task line: three execution forms of the same subject (cont.)

tiers where the framework under test is faster

the framework under test is slower at 75 tiers, across 5 baselines.

apscheduler is faster at 13 tiers

asyncio_pool is faster at 16 tiers

bare_thread is faster at 16 tiers

process_pool is faster at 15 tiers

thread_pool is faster at 15 tiers

Openly published unfavourable data

Openly published unfavourable data (cont.)

Openly published unfavourable data (cont.)

Openly published unfavourable data (cont.)

Openly published unfavourable data (cont.)

Openly published unfavourable data (cont.)

Openly published unfavourable data (cont.)

tiers with no winner

tiers with no winner (cont.)

caliber limitations and sources of bias

caliber limitations and sources of bias (cont.)

the rest of this section's details are in the full report

bring your own baseline

self-check

every slide can be checked verbatim in the full report

zoo-framework 0.6.0
benchmark