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

zoo-framework 0.8.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.8.0/20261011T092340Z.json

zoo-bench report

Run environment

itemvalue
CPU modelAMD EPYC 7763 64-Core Processor
logical cores4
platformLinux-x86_64
operating systemLinux 6.17.0-1022-azure (#22-Ubuntu SMP Mon Jul 27 17:24:03 UTC 2026)
PythonCPython 3.13.16
interpreter/opt/hostedtoolcache/Python/3.13.16/x64/bin/python
GILdefault
framework under test (distribution metadata)0.8.0
framework under test (module __version__)0.8.0 (footnote only, not the version criterion)
drive-surface generation of the framework under testcurrent-generation drive surface (scheduling core + scheduling model; the completion signal comes from the result reactor)
harnesszoo-bench 0.0.1 @ 9a42be24ac43f75e2e5d7b16434f91ba3d0717b6
command to reproducezoo-bench run --framework zoo-framework==0.8.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 2700 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 and a 40 microsecond body, the framework under test is 2.12x faster than process_pool (the fastest measured tier at that concurrency).
  • At concurrency 1, once the body exceeds about 40 microseconds, apscheduler is no longer faster than the framework under test.
  • At concurrency 4, once the body exceeds about 40 microseconds, apscheduler is no longer faster than the framework under test.
  • At concurrency 16, once the body exceeds about 40 microseconds, apscheduler is no longer faster than the framework under test.

data: Conclusion summary

Conclusion summary

Conclusion summary (cont.)

  • At concurrency 64, once the body exceeds about 40 microseconds, apscheduler is no longer faster than the framework under test.
  • At concurrency 1, once the body exceeds about 40 microseconds, asyncio_pool is no longer faster than the framework under test.
  • At concurrency 4, 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.
  • At concurrency 16, 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 8 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

1.50%

Framework overhead share of zoo at body tier 10000 microseconds.
2 baselines are lower at this tier: bare_thread, thread_pool.
same-tier comparison: apscheduler 3.60%, asyncio_pool 1.58%, bare_thread 1.33%, process_pool 3.39%, thread_pool 0.73%

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
174.06 microseconds
apscheduler
281.24 microseconds
asyncio_pool
213.36 microseconds
bare_thread
144.76 microseconds
process_pool
369.75 microseconds
thread_pool
77.28 microseconds
body tier 300 microseconds
zoo
433.22 microseconds
apscheduler
544.52 microseconds
asyncio_pool
405.28 microseconds
bare_thread
396.70 microseconds
process_pool
614.59 microseconds
thread_pool
324.43 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
2.800 milliseconds
apscheduler
2.884 milliseconds
asyncio_pool
2.701 milliseconds
bare_thread
2.680 milliseconds
process_pool
2.982 milliseconds
thread_pool
2.658 milliseconds
body tier 10000 microseconds
zoo
9.885 milliseconds
apscheduler
10.156 milliseconds
asyncio_pool
9.700 milliseconds
bare_thread
9.548 milliseconds
process_pool
10.087 milliseconds
thread_pool
9.698 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

concurrencybody tier (microseconds)zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
140174.06 microseconds281.24 microseconds213.36 microseconds144.76 microseconds369.75 microseconds77.28 microseconds
1300433.22 microseconds544.52 microseconds405.28 microseconds396.70 microseconds614.59 microseconds324.43 microseconds
127002.800 milliseconds2.884 milliseconds2.701 milliseconds2.680 milliseconds2.982 milliseconds2.658 milliseconds
1100009.885 milliseconds10.156 milliseconds9.700 milliseconds9.548 milliseconds10.087 milliseconds9.698 milliseconds
440200.10 microseconds255.42 microseconds156.05 microseconds168.63 microseconds191.30 microseconds96.24 microseconds
4300457.43 microseconds516.26 microseconds407.59 microseconds412.07 microseconds341.25 microseconds352.35 microseconds
427002.814 milliseconds2.983 milliseconds2.764 milliseconds2.728 milliseconds1.359 milliseconds2.711 milliseconds
41000010.050 milliseconds10.101 milliseconds9.786 milliseconds9.829 milliseconds4.650 milliseconds9.811 milliseconds
1640199.72 microseconds246.53 microseconds130.72 microseconds170.14 microseconds152.53 microseconds88.97 microseconds
16300464.10 microseconds520.81 microseconds392.41 microseconds419.21 microseconds277.10 microseconds354.95 microseconds

data: Dimension: Latency percentiles and jitter

Dimension: Latency percentiles and jitter

Dimension: Latency percentiles and jitter (cont.)

concurrencybody tier (microseconds)zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
1627002.869 milliseconds2.998 milliseconds2.756 milliseconds2.682 milliseconds1.413 milliseconds2.133 milliseconds
161000010.104 milliseconds10.223 milliseconds9.931 milliseconds9.895 milliseconds4.698 milliseconds9.734 milliseconds
6440195.85 microseconds245.59 microseconds123.00 microseconds174.50 microseconds200.04 microseconds90.65 microseconds
64300465.14 microseconds514.29 microseconds381.41 microseconds426.28 microseconds310.51 microseconds353.92 microseconds
6427002.881 milliseconds2.940 milliseconds2.804 milliseconds2.775 milliseconds1.375 milliseconds2.774 milliseconds
641000010.631 milliseconds9.958 milliseconds10.397 milliseconds9.824 milliseconds4.637 milliseconds10.331 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
71.17%
apscheduler
82.72%
asyncio_pool
69.72%
bare_thread
63.87%
process_pool
84.78%
thread_pool
39.13%
body tier 300 microseconds
zoo
30.28%
apscheduler
45.98%
asyncio_pool
26.53%
bare_thread
25.54%
process_pool
49.47%
thread_pool
11.12%
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
4.86%
apscheduler
10.26%
asyncio_pool
4.58%
bare_thread
4.26%
process_pool
11.34%
thread_pool
1.81%
body tier 10000 microseconds
zoo
1.50%
apscheduler
3.60%
asyncio_pool
1.58%
bare_thread
1.33%
process_pool
3.39%
thread_pool
0.73%
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)

concurrencybody tier (microseconds)zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
14071.17%82.72%69.72%63.87%84.78%39.13%
130030.28%45.98%26.53%25.54%49.47%11.12%
127004.86%10.26%4.58%4.26%11.34%1.81%
1100001.50%3.60%1.58%1.33%3.39%0.73%
44072.44%78.18%65.64%69.06%53.06%48.39%
430033.04%40.22%25.72%28.67%-15.31%

data: Dimension: Framework overhead share

Dimension: Framework overhead share

Dimension: Framework overhead share (cont.)

concurrencybody tier (microseconds)zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
427007.13%9.79%4.02%4.69%-3.67%
410000------
1640------
16300------
162700------
1610000------
6440------
64300------
642700------
6410000------

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
5,745 tasks/s
apscheduler
3,556 tasks/s
asyncio_pool
4,687 tasks/s
bare_thread
6,908 tasks/s
process_pool
2,705 tasks/s
thread_pool
12,939 tasks/s
body tier 300 microseconds
zoo
2,308 tasks/s
apscheduler
1,836 tasks/s
asyncio_pool
2,467 tasks/s
bare_thread
2,521 tasks/s
process_pool
1,627 tasks/s
thread_pool
3,082 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
357 tasks/s
apscheduler
347 tasks/s
asyncio_pool
370 tasks/s
bare_thread
373 tasks/s
process_pool
335 tasks/s
thread_pool
376 tasks/s
body tier 10000 microseconds
zoo
101 tasks/s
apscheduler
98 tasks/s
asyncio_pool
103 tasks/s
bare_thread
105 tasks/s
process_pool
99 tasks/s
thread_pool
103 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

concurrencybody tier (microseconds)zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
1405745.33555.74686.86907.92704.512939.1
13002308.31836.52467.42520.81627.13082.3
12700357.2346.7370.2373.2335.3376.2
110000101.298.5103.1104.799.1103.1
44019989.915660.325632.923720.320909.541562.7
43008744.67748.09813.89707.111721.511352.2
427001421.51340.81447.41466.12944.31475.5
410000398.0396.0408.8407.0860.2407.7
164080111.564899.7122396.194038.7104898.1179841.5
1630034475.330721.340773.238167.257740.145076.5
1627005576.05337.65805.45965.911327.37501.0

data: Dimension: Throughput and concurrency scaling

Dimension: Throughput and concurrency scaling

Dimension: Throughput and concurrency scaling (cont.)

concurrencybody tier (microseconds)zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
16100001583.61565.01611.11617.03406.01643.7
6440326787.3260593.3520342.3366766.2319932.6705985.9
64300137591.9124444.1167797.3150135.6206112.0180832.2
64270022213.721770.522823.423067.046544.623074.4
64100006020.16427.26155.56514.513803.06194.7

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 17 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: ok (the conclusion was reached on the 'current' drive-surface generation installed during this measurement)

semantics itemlayerhow probedmeasurableevidence / reason
timeoutdispatch layerbehavioral probe (driven repeatedly through scheduling rounds; measures the moment the worker leaves the in-flight table)yestimeout reap observed: the worker left the in-flight table before the body ended (0.0123s) (body 0.15s, run_timeout 0.01s); judgment action at dispatch_core.py:365; what is in effect is observation and circuit-breaking (recording, marking unhealthy, removing the in-flight registration, stopping dispatch), not termination of the still-running worker - CPython cannot safely interrupt a running thread
priorityevent layerstructural probe (checks whether the symbols required for execution exist)nonot re-checked: this item's conclusion was reached on the 'previous' generation; taking it as this generation's fact asserts wiring in the report that the current generation does not have. Re-deriving it needs a probe design of its own (each item needs clean on/off states before it can be priced)
retryevent layerstructural probe (checks whether the symbols required for execution exist)nonot re-checked: this item's conclusion was reached on the 'previous' generation; taking it as this generation's fact asserts wiring in the report that the current generation does not have. Re-deriving it needs a probe design of its own (each item needs clean on/off states before it can be priced)

data: Dimension: The cost of scheduling semantics

Dimension: The cost of scheduling semantics

Dimension: The cost of scheduling semantics (cont.)

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.

baselineconcurrencybody tier (microseconds)gapmedian of the framework under test
apscheduler140the framework under test is 1.62x faster than apscheduler174.06 microseconds
process_pool140the framework under test is 2.12x faster than process_pool174.06 microseconds
apscheduler1300the framework under test is 1.26x faster than apscheduler433.22 microseconds
process_pool1300the framework under test is 1.42x faster than process_pool433.22 microseconds
apscheduler12700the framework under test is 1.03x faster than apscheduler2.800 milliseconds

data: tiers where the framework under test is faster

tiers where the framework under test is faster

tiers where the framework under test is faster (cont.)

baselineconcurrencybody tier (microseconds)gapmedian of the framework under test
process_pool12700the framework under test is 1.07x faster than process_pool2.800 milliseconds
apscheduler110000the framework under test is 1.03x faster than apscheduler9.885 milliseconds
process_pool110000the framework under test is 1.02x faster than process_pool9.885 milliseconds
apscheduler440the framework under test is 1.28x faster than apscheduler200.10 microseconds
apscheduler4300the framework under test is 1.13x faster than apscheduler457.43 microseconds
apscheduler42700the framework under test is 1.06x faster than apscheduler2.814 milliseconds
apscheduler1640the framework under test is 1.23x faster than apscheduler199.72 microseconds
apscheduler16300the framework under test is 1.12x faster than apscheduler464.10 microseconds
apscheduler162700the framework under test is 1.04x faster than apscheduler2.869 milliseconds
apscheduler6440the framework under test is 1.25x faster than apscheduler195.85 microseconds
apscheduler64300the framework under test is 1.11x faster than apscheduler465.14 microseconds

data: tiers where the framework under test is faster

Openly published unfavourable data - summary

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

apscheduler is faster at 1 tiers

worst 1.07x (concurrency 64 at 10000 microseconds). All tiers: concurrency 64 at 10000 microseconds

asyncio_pool is faster at 12 tiers

worst 1.59x (concurrency 64 at 40 microseconds). All tiers: 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 16 at 10000 microseconds, concurrency 64 at 40 microseconds, concurrency 64 at 300 microseconds, concurrency 64 at 2700 microseconds

bare_thread is faster at 13 tiers

worst 1.17x (concurrency 16 at 40 microseconds). All tiers: concurrency 1 at 2700 microseconds, concurrency 1 at 10000 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 10 tiers

worst 2.29x (concurrency 64 at 10000 microseconds). All tiers: 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 300 microseconds, concurrency 64 at 2700 microseconds, concurrency 64 at 10000 microseconds

thread_pool is faster at 15 tiers

worst 2.25x (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

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.

baselineconcurrencybody tier (microseconds)gapmedian of the framework under test
thread_pool140thread_pool is 2.25x faster than zoo174.06 microseconds
thread_pool1300thread_pool is 1.34x faster than zoo433.22 microseconds
asyncio_pool12700asyncio_pool is 1.04x faster than zoo2.800 milliseconds
bare_thread12700bare_thread is 1.04x faster than zoo2.800 milliseconds
thread_pool12700thread_pool is 1.05x faster than zoo2.800 milliseconds
asyncio_pool110000asyncio_pool is 1.02x faster than zoo9.885 milliseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baselineconcurrencybody tier (microseconds)gapmedian of the framework under test
bare_thread110000bare_thread is 1.04x faster than zoo9.885 milliseconds
thread_pool110000thread_pool is 1.02x faster than zoo9.885 milliseconds
asyncio_pool440asyncio_pool is 1.28x faster than zoo200.10 microseconds
thread_pool440thread_pool is 2.08x faster than zoo200.10 microseconds
asyncio_pool4300asyncio_pool is 1.12x faster than zoo457.43 microseconds
bare_thread4300bare_thread is 1.11x faster than zoo457.43 microseconds
process_pool4300process_pool is 1.34x faster than zoo457.43 microseconds
thread_pool4300thread_pool is 1.30x faster than zoo457.43 microseconds
bare_thread42700bare_thread is 1.03x faster than zoo2.814 milliseconds
process_pool42700process_pool is 2.07x faster than zoo2.814 milliseconds
thread_pool42700thread_pool is 1.04x faster than zoo2.814 milliseconds
asyncio_pool410000asyncio_pool is 1.03x faster than zoo10.050 milliseconds
bare_thread410000bare_thread is 1.02x faster than zoo10.050 milliseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baselineconcurrencybody tier (microseconds)gapmedian of the framework under test
process_pool410000process_pool is 2.16x faster than zoo10.050 milliseconds
thread_pool410000thread_pool is 1.02x faster than zoo10.050 milliseconds
asyncio_pool1640asyncio_pool is 1.53x faster than zoo199.72 microseconds
bare_thread1640bare_thread is 1.17x faster than zoo199.72 microseconds
process_pool1640process_pool is 1.31x faster than zoo199.72 microseconds
thread_pool1640thread_pool is 2.24x faster than zoo199.72 microseconds
asyncio_pool16300asyncio_pool is 1.18x faster than zoo464.10 microseconds
bare_thread16300bare_thread is 1.11x faster than zoo464.10 microseconds
process_pool16300process_pool is 1.67x faster than zoo464.10 microseconds
thread_pool16300thread_pool is 1.31x faster than zoo464.10 microseconds
asyncio_pool162700asyncio_pool is 1.04x faster than zoo2.869 milliseconds
bare_thread162700bare_thread is 1.07x faster than zoo2.869 milliseconds
process_pool162700process_pool is 2.03x faster than zoo2.869 milliseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baselineconcurrencybody tier (microseconds)gapmedian of the framework under test
thread_pool162700thread_pool is 1.35x faster than zoo2.869 milliseconds
asyncio_pool1610000asyncio_pool is 1.02x faster than zoo10.104 milliseconds
bare_thread1610000bare_thread is 1.02x faster than zoo10.104 milliseconds
process_pool1610000process_pool is 2.15x faster than zoo10.104 milliseconds
thread_pool1610000thread_pool is 1.04x faster than zoo10.104 milliseconds
asyncio_pool6440asyncio_pool is 1.59x faster than zoo195.85 microseconds
bare_thread6440bare_thread is 1.12x faster than zoo195.85 microseconds
thread_pool6440thread_pool is 2.16x faster than zoo195.85 microseconds
asyncio_pool64300asyncio_pool is 1.22x faster than zoo465.14 microseconds
bare_thread64300bare_thread is 1.09x faster than zoo465.14 microseconds
process_pool64300process_pool is 1.50x faster than zoo465.14 microseconds
thread_pool64300thread_pool is 1.31x faster than zoo465.14 microseconds
asyncio_pool642700asyncio_pool is 1.03x faster than zoo2.881 milliseconds

data: Openly published unfavourable data

Openly published unfavourable data

Openly published unfavourable data (cont.)

baselineconcurrencybody tier (microseconds)gapmedian of the framework under test
bare_thread642700bare_thread is 1.04x faster than zoo2.881 milliseconds
process_pool642700process_pool is 2.10x faster than zoo2.881 milliseconds
thread_pool642700thread_pool is 1.04x faster than zoo2.881 milliseconds
apscheduler6410000apscheduler is 1.07x faster than zoo10.631 milliseconds
bare_thread6410000bare_thread is 1.08x faster than zoo10.631 milliseconds
process_pool6410000process_pool is 2.29x faster than zoo10.631 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.0% to 35.2% (it varies with each tier's spread).

data: tiers with no winner

tiers with no winner

tiers with no winner (cont.)

baselineconcurrencybody tier (microseconds)ratioreason
asyncio_pool1401.23xthe two sides differ by 22.6%, less than the band of 35.2% - no winner
bare_thread1400.83xthe two sides differ by 16.8%, less than the band of 19.7% - no winner
asyncio_pool13000.94xthe two sides differ by 6.4%, less than the band of 8.8% - no winner
bare_thread13000.92xthe two sides differ by 8.4%, less than the band of 9.5% - no winner
bare_thread4400.84xthe two sides differ by 15.7%, less than the band of 27.2% - no winner
process_pool4400.96xthe two sides differ by 4.4%, less than the band of 16.2% - no winner
asyncio_pool427000.98xthe two sides differ by 1.8%, less than the band of 3.1% - no winner
apscheduler4100001.01xthe two sides differ by 0.5%, less than the band of 1.4% - no winner
apscheduler16100001.01xthe two sides differ by 1.2%, less than the band of 1.7% - no winner
process_pool64401.02xthe two sides differ by 2.1%, less than the band of 11.5% - no winner
apscheduler6427001.02xthe two sides differ by 2.0%, less than the band of 3.0% - no winner
asyncio_pool64100000.98xthe two sides differ by 2.2%, less than the band of 3.8% - no winner
thread_pool64100000.97xthe two sides differ by 2.8%, less than the band of 3.4% - 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': 29954, 'child_pids': [30410, 30413, 30416, 30419, 30422, 30428, 30434, 30440, 30446, 30464, 30482, 30500, 30521, 30577, 30634, 30692, 30758, 30760, 30762, 30764, 30766, 30771, 30776, 30781, 30786, 30803, 30821, 30838, 30856, 30918, 30977, 31039, 31104, 31138, 31172, 31206, 31240, 31373, 31506, 31639, 31772, 32301, 32830, 33359, 33888, 36001, 38115, 40228, 42343, 42347, 42351, 42355, 42359, 42366, 42373, 42380, 42387, 42406, 42425, 42444, 42463, 42530, 42597, 42664, 42732, 42734, 42736, 42738, 42740, 42745, 42750, 42755, 42760, 42777, 42794, 42811, 42829, 42885, 42941, 43000, 43068, 43070, 43072, 430

data: self-check

self-check

self-check (cont.)

  • 74, 43076, 43081, 43086, 43091, 43096, 43113, 43130, 43147, 43164, 43205, 43239, 43280], '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.8.0/20261011T092340Z.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.

← / → · space · R reset