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

zoo-framework 0.9.0
性能评测

与 apscheduler、asyncio_pool、bare_thread、process_pool、thread_pool 共 5 个对照方案的同口径对比；全部数值由 zoo-bench 在本机重新测量、逐档公开，包括本框架输掉的档位。

原始数据：results/zoo-framework-0.9.0/20261011T092749Z.json

zoo-bench 报告

运行环境

项值
CPU 型号AMD EPYC 7763 64-Core Processor
逻辑核数4
平台Linux-x86_64
操作系统Linux 6.17.0-1022-azure（#22-Ubuntu SMP Mon Jul 27 17:24:03 UTC 2026）
PythonCPython 3.13.16
解释器/opt/hostedtoolcache/Python/3.13.16/x64/bin/python
GILdefault
被测框架（发行元数据）0.9.0
被测框架（模块 __version__）0.9.0（仅附注，不作版本判据）
被测框架的驱动面世代当前代驱动面（调度内核 core + 调度模型 model，完成信号取自结果响应器）
harnesszoo-bench 0.0.1 @ 9a42be24ac43f75e2e5d7b16434f91ba3d0717b6
复现命令zoo-bench run --framework zoo-framework==0.9.0

数据：运行环境

运行环境

运行环境（续）

以 dist_version（发行元数据）为版本真源；module_version 仅作附注

数据：运行环境

zoo-bench 报告

负载

  • 构成：单位工作 = JSON 序列化 + 反序列化 + 字符串拼接，重复若干次以达到目标耗时；档位由 matrix.yaml 的 body_tiers_us 声明
  • 负载是替身，不是真实 trace：形状接近“取一帧数据 -> 序列化 -> 解析 -> 字符串处理”这类业务动作，但仓库内没有真实样本，结论的适用性以此为前提

数据：负载

zoo-bench 报告

测量口径

  • 执行体耗时在同一次运行内埋点：由执行体在自身内部测量并回传，框架开销 =端到端 - 它。不做跨运行减法——两次运行的状态不同（缓存、频率、调度噪声），相减引入的是系统性偏差。
  • 预热不入统计：每个单元先跑 3 轮预热并丢弃，只统计随后的 30 轮正式采样；采样数等于「正式轮数 x 并发度」。
  • 绝对耗时不可跨运行比较：它只用于看量级；跨版本/跨机器要看的是同一次运行内的相对量（开销占比、相对各对照方案的倍数），它们对整体快慢不敏感。

数据：测量口径

zoo-bench 报告

结论摘要

  • 被测框架 zoo 的执行体时长达到约 2700 微秒 及以上时，其框架开销占端到端的比例降到 15% 以下；短于此档位，选用它的主要代价就是框架开销本身。
  • 并发度 1、执行体 40 微秒 下，被测框架比 process_pool 快 1.83x（该并发度所测档位中最快的一档）。
  • 并发度 1 下，执行体时长超过约 40 微秒 后，apscheduler 不再快于被测框架。
  • 并发度 4 下，执行体时长超过约 40 微秒 后，apscheduler 不再快于被测框架。
  • 并发度 16 下，执行体时长超过约 40 微秒 后，apscheduler 不再快于被测框架。
  • 并发度 64 下，执行体时长超过约 40 微秒 后，apscheduler 不再快于被测框架。
  • 并发度 1 下，所测档位内 asyncio_pool 始终快于被测框架——这类档位正是本报告的公开不利数据。

数据：结论摘要

结论摘要

结论摘要（续）

  • 并发度 4 下，所测档位内 asyncio_pool 始终快于被测框架——这类档位正是本报告的公开不利数据。
  • 并发度 16 下，所测档位内 asyncio_pool 始终快于被测框架——这类档位正是本报告的公开不利数据。
  • 并发度 64 下，所测档位内 asyncio_pool 始终快于被测框架——这类档位正是本报告的公开不利数据。
  • 并发度 1 下，所测档位内 bare_thread 始终快于被测框架——这类档位正是本报告的公开不利数据。
  • 并发度 4 下，所测档位内 bare_thread 始终快于被测框架——这类档位正是本报告的公开不利数据。
  • 并发度 16 下，所测档位内 bare_thread 始终快于被测框架——这类档位正是本报告的公开不利数据。
  • 并发度 64 下，所测档位内 bare_thread 始终快于被测框架——这类档位正是本报告的公开不利数据。

数据：结论摘要

结论摘要

本章其余明细在全文里

幻灯片为了「一页一个结论」只放了本章的前 2 页；余下 6 页的逐单元数值、分位数与原始样本都在全文的同一章节里，逐字可核。

全文：同目录 report.md 的「结论摘要」章节

结论摘要 · 框架自身开销占比

2.55%

执行体 10000 微秒 时，zoo 的框架自身开销占比。
该档位有 3 个方案更低：asyncio_pool、bare_thread、thread_pool。
同档对比：apscheduler 3.19%、asyncio_pool 1.54%、bare_thread 1.25%、process_pool 3.45%、thread_pool 0.67%

数据：zoo-bench「框架自身开销占比」· 并发度 1 · 执行体 10000 微秒 档

维度：延迟分位数与抖动

延迟分位数与抖动：并发度 1

并发度 1 · 端到端 / 并发度

执行体 40 微秒
zoo
182.57 微秒
apscheduler
288.52 微秒
asyncio_pool
140.37 微秒
bare_thread
148.91 微秒
process_pool
333.53 微秒
thread_pool
75.77 微秒
执行体 300 微秒
zoo
449.17 微秒
apscheduler
542.76 微秒
asyncio_pool
386.47 微秒
bare_thread
384.68 微秒
process_pool
607.37 微秒
thread_pool
322.77 微秒
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

数据：zoo-bench「延迟分位数与抖动」· 并发度 1 · 逐单元数值与分位数见 report.md 的同一章节

维度：延迟分位数与抖动

延迟分位数与抖动：并发度 1（续）

并发度 1 · 端到端 / 并发度

执行体 2700 微秒
zoo
2.754 毫秒
apscheduler
2.999 毫秒
asyncio_pool
2.752 毫秒
bare_thread
2.672 毫秒
process_pool
3.009 毫秒
thread_pool
2.689 毫秒
执行体 10000 微秒
zoo
10.066 毫秒
apscheduler
9.971 毫秒
asyncio_pool
9.482 毫秒
bare_thread
9.648 毫秒
process_pool
9.888 毫秒
thread_pool
9.361 毫秒
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

数据：zoo-bench「延迟分位数与抖动」· 并发度 1 · 逐单元数值与分位数见 report.md 的同一章节

zoo-bench 报告

维度：延迟分位数与抖动

端到端 / 并发度；分位数与相对离散度同表给出，只给中位数的度量不合格

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
140182.57 微秒288.52 微秒140.37 微秒148.91 微秒333.53 微秒75.77 微秒
1300449.17 微秒542.76 微秒386.47 微秒384.68 微秒607.37 微秒322.77 微秒
127002.754 毫秒2.999 毫秒2.752 毫秒2.672 毫秒3.009 毫秒2.689 毫秒
11000010.066 毫秒9.971 毫秒9.482 毫秒9.648 毫秒9.888 毫秒9.361 毫秒
440206.14 微秒256.36 微秒173.04 微秒199.87 微秒168.78 微秒96.03 微秒
4300485.26 微秒511.06 微秒407.48 微秒419.42 微秒304.29 微秒350.77 微秒
427002.946 毫秒2.983 毫秒2.755 毫秒2.706 毫秒1.385 毫秒2.742 毫秒
41000010.106 毫秒10.258 毫秒9.867 毫秒9.696 毫秒4.621 毫秒9.813 毫秒
1640205.75 微秒224.01 微秒134.08 微秒167.78 微秒149.92 微秒90.21 微秒
16300470.57 微秒505.14 微秒393.00 微秒424.88 微秒278.51 微秒343.15 微秒
1627002.899 毫秒2.980 毫秒2.802 毫秒2.711 毫秒1.370 毫秒2.772 毫秒

数据：维度：延迟分位数与抖动

维度：延迟分位数与抖动

维度：延迟分位数与抖动（续）

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
161000010.084 毫秒9.881 毫秒9.935 毫秒9.609 毫秒4.741 毫秒9.803 毫秒
6440207.28 微秒220.85 微秒120.26 微秒171.52 微秒194.08 微秒89.21 微秒
64300491.01 微秒501.75 微秒384.40 微秒424.30 微秒299.76 微秒350.35 微秒
6427002.953 毫秒2.965 毫秒2.811 毫秒2.675 毫秒1.364 毫秒2.696 毫秒
641000010.538 毫秒10.167 毫秒10.407 毫秒9.827 毫秒4.686 毫秒10.244 毫秒

逐单元数值（分位数、离散度、各轮原始样本）见文末「附录：全部数值」。

数据：维度：延迟分位数与抖动

维度：框架自身开销占比

框架自身开销占比：并发度 1

并发度 1 · 框架自身开销

执行体 40 微秒
zoo
71.66%
apscheduler
79.81%
asyncio_pool
67.08%
bare_thread
64.13%
process_pool
83.82%
thread_pool
41.38%
执行体 300 微秒
zoo
32.12%
apscheduler
44.93%
asyncio_pool
26.24%
bare_thread
25.34%
process_pool
48.87%
thread_pool
11.10%
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

数据：zoo-bench「框架自身开销占比」· 并发度 1 · 逐单元数值与分位数见 report.md 的同一章节

维度：框架自身开销占比

框架自身开销占比：并发度 1（续）

并发度 1 · 框架自身开销

执行体 2700 微秒
zoo
5.65%
apscheduler
9.02%
asyncio_pool
4.58%
bare_thread
4.02%
process_pool
11.37%
thread_pool
2.35%
执行体 10000 微秒
zoo
2.55%
apscheduler
3.19%
asyncio_pool
1.54%
bare_thread
1.25%
process_pool
3.45%
thread_pool
0.67%
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

数据：zoo-bench「框架自身开销占比」· 并发度 1 · 逐单元数值与分位数见 report.md 的同一章节

zoo-bench 报告

维度：框架自身开销占比

开销 = 端到端/并发度 - 同一次运行内实测的执行体耗时（不做跨运行减法）。带 — 的格：该并发度超出这台机器的并行能力，执行体自报耗时含超订的调度等待，与该行的每任务端到端不可比，故不给开销数字（端到端与吞吐见各自的维度）

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
14071.66%79.81%67.08%64.13%83.82%41.38%
130032.12%44.93%26.24%25.34%48.87%11.10%
127005.65%9.02%4.58%4.02%11.37%2.35%
1100002.55%3.19%1.54%1.25%3.45%0.67%
44073.26%78.08%68.70%70.52%67.43%48.25%
430036.28%39.64%25.85%28.21%—14.92%
427007.68%8.71%4.45%4.05%—2.85%
410000——————
1640——————
16300——————
162700——————

数据：维度：框架自身开销占比

维度：框架自身开销占比

维度：框架自身开销占比（续）

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
1610000——————
6440——————
64300——————
642700——————
6410000——————

逐单元数值（分位数、离散度、各轮原始样本）见文末「附录：全部数值」。

数据：维度：框架自身开销占比

维度：吞吐与并发伸缩

吞吐与并发伸缩：并发度 1

并发度 1 · 吞吐

执行体 40 微秒
zoo
5,477 任务/秒
apscheduler
3,466 任务/秒
asyncio_pool
7,124 任务/秒
bare_thread
6,716 任务/秒
process_pool
2,998 任务/秒
thread_pool
13,198 任务/秒
执行体 300 微秒
zoo
2,226 任务/秒
apscheduler
1,842 任务/秒
asyncio_pool
2,588 任务/秒
bare_thread
2,600 任务/秒
process_pool
1,646 任务/秒
thread_pool
3,098 任务/秒
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

数据：zoo-bench「吞吐与并发伸缩」· 并发度 1 · 逐单元数值与分位数见 report.md 的同一章节

维度：吞吐与并发伸缩

吞吐与并发伸缩：并发度 1（续）

并发度 1 · 吞吐

执行体 2700 微秒
zoo
363 任务/秒
apscheduler
333 任务/秒
asyncio_pool
363 任务/秒
bare_thread
374 任务/秒
process_pool
332 任务/秒
thread_pool
372 任务/秒
执行体 10000 微秒
zoo
99 任务/秒
apscheduler
100 任务/秒
asyncio_pool
105 任务/秒
bare_thread
104 任务/秒
process_pool
101 任务/秒
thread_pool
107 任务/秒
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

数据：zoo-bench「吞吐与并发伸缩」· 并发度 1 · 逐单元数值与分位数见 report.md 的同一章节

zoo-bench 报告

维度：吞吐与并发伸缩

吞吐 = 并发度 / 端到端中位数；随并发度是否继续上升即为伸缩性

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
1405477.43466.07123.96715.52998.213198.4
13002226.31842.42587.52599.61646.43098.1
12700363.1333.4363.4374.3332.3371.9
11000099.3100.3105.5103.6101.1106.8
44019404.415602.923116.520013.023699.241654.8
43008242.97826.89816.59537.013145.411403.4
427001357.71341.01451.91478.12888.81459.0
410000395.8389.9405.4412.6865.5407.6
164077763.471424.4119331.095364.7106727.0177361.2
1630034001.331674.540712.637658.157448.946626.5
1627005518.75369.85711.15901.511678.35772.6

数据：维度：吞吐与并发伸缩

维度：吞吐与并发伸缩

维度：吞吐与并发伸缩（续）

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
16100001586.71619.21610.51665.23375.11632.1
6440308754.3289794.7532160.1373124.9329761.1717389.6
64300130343.7127553.4166491.4150836.5213501.9182674.1
64270021671.421585.822767.323921.946909.723741.9
64100006073.56294.86149.56512.813657.96247.3

逐单元数值（分位数、离散度、各轮原始样本）见文末「附录：全部数值」。

数据：维度：吞吐与并发伸缩

zoo-bench 报告

维度：开销归因

口径：把每任务端到端拆成提交侧 / 手交 / 执行体 / 回程四段，并在同一档位与并发度下与各对照方案逐段对照，回答「超出对照的部分落在哪一段」。它是诊断而非主证据：抽样一小批档位，且不与对照方案比总开销。手交为负不是错误：那表示提交调用还没返回、执行体就已经开跑——把建线程一类工作算进提交侧的方案就会这样（实测 bare_thread 手交 -343 微秒）。回程含完成信号的等待（排空返回前的最后一段），它与主测量是同一口径

状态：ok

本维度是诊断不是主证据：抽样的档位与并发度固定为一小批，不覆盖矩阵里的全部单元。并发度上界取机器的并行能力——超过它时量到的是争用；

抽样档位（微秒）：40、10000；并发度：[1, 4]；该机器并行能力：4

方案并发度档位（微秒）提交侧手交执行体回程状态
apscheduler140108.78 微秒81.29 微秒58.86 微秒42.86 微秒ok
apscheduler440110.68 微秒519.28 微秒56.18 微秒218.97 微秒ok
apscheduler110000166.72 微秒122.62 微秒9.782 毫秒59.54 微秒ok

数据：维度：开销归因

维度：开销归因

维度：开销归因（续）

方案并发度档位（微秒）提交侧手交执行体回程状态
apscheduler410000119.74 微秒12.884 毫秒14.542 毫秒9.805 毫秒ok
asyncio_pool14027.40 微秒47.40 微秒56.28 微秒78.36 微秒ok
asyncio_pool44019.00 微秒259.15 微秒54.13 微秒309.16 微秒ok
asyncio_pool11000022.65 微秒36.13 微秒9.197 毫秒84.50 微秒ok
asyncio_pool41000023.82 微秒12.044 毫秒14.259 毫秒9.649 毫秒ok
bare_thread140141.09 微秒-77.35 微秒52.12 微秒31.62 微秒ok
bare_thread440150.71 微秒-74.46 微秒50.79 微秒302.37 微秒ok
bare_thread1100005.173 毫秒-5094.45 微秒9.675 毫秒38.67 微秒ok
bare_thread4100005.189 毫秒-5084.41 微秒14.786 毫秒9.975 毫秒ok
process_pool140————not_measurable：执行体的起止时刻读不到——它没有在本进程里运行（跨进程档位无法这样分段）
process_pool440————not_measurable：执行体的起止时刻读不到——它没有在本进程里运行（跨进程档位无法这样分段）
process_pool110000————not_measurable：执行体的起止时刻读不到——它没有在本进程里运行（跨进程档位无法这样分段）
process_pool410000————not_measurable：执行体的起止时刻读不到——它没有在本进程里运行（跨进程档位无法这样分段）

数据：维度：开销归因

维度：开销归因

本章其余明细在全文里

幻灯片为了「一页一个结论」只放了本章的前 2 页；余下 9 页的逐单元数值、分位数与原始样本都在全文的同一章节里，逐字可核。

全文：同目录 report.md 的「维度：开销归因」章节

zoo-bench 报告

维度：调度语义的代价

口径：本维度采用内部开关对照（同一 workload 下语义全关 vs 逐个开启），不与对照方案横向比较——裸写法没有优先级/超时/重试的对应物，故只能回答“本框架的语义值多少钱”，不能回答“比裸写法贵多少”

状态：ok（结论在该次测量装着的「current」代驱动面上得出）

语义项层级探查方式可测证据 / 原因
超时派发层行为探查（按调度轮反复驱动，量在飞表摘除时刻）是已观测到超时摘除：在执行体结束之前离开在飞表（0.0122s）（执行体 0.15s、run_timeout 0.01s）；判定动作在 dispatch_core.py:425；生效的是观测与熔断（记录、标记不健康、摘除在飞登记、停止派发），不是终止仍在执行的 worker——CPython 无法安全中断线程
优先级事件层结构探查（检查执行所需的符号是否存在）否未复核：本项的结论是在「previous」代上得出的，把它当成本代的事实等于在报告里断言一个当前代并不具备的接线。重新推导需要单独一次探查设计（每项要有干净的开/关态才谈得上定价）
重试事件层结构探查（检查执行所需的符号是否存在）否未复核：本项的结论是在「previous」代上得出的，把它当成本代的事实等于在报告里断言一个当前代并不具备的接线。重新推导需要单独一次探查设计（每项要有干净的开/关态才谈得上定价）

本结论按被测版本得出，坐标只对该版本成立；往 matrix.yaml 追加版本后须重跑本探查

数据：维度：调度语义的代价

zoo-bench 报告

维度：原生任务线：同一被测对象的三种执行形态

口径：该线独立测量：它不进入主矩阵的透视表与交叉点，其数值也不可与那些表里的对照方案横向比较

该线结论：not_applicable

被测框架不具备该能力（找不到这些符号：adaptive_params, dual_arm_worker, native_params, native_task_worker）——该线对此版本不适用，这不是失败

等价性门禁：未跑到（前置探查没走到这一步）

所测任务 modbus_rtu.parse_response——Modbus RTU 响应帧解析：输入是一条裸 RTU ADU 响应帧（不含任何传输层封装），其长度即该档位的帧字节

规模档位 R1、R8、R125（帧字节 7、21、255）；并发度 1、4、16、64；每格预热 100 轮 + 采样 100 轮，每个并发度一个子进程（共 4 个）

数据：维度：原生任务线：同一被测对象的三种执行形态

zoo-bench 报告

被测框架在哪些档位更快

被测框架处于优势的档位（两侧差异大于该档位的带宽）。它与「公开的不利数据」出自同一份同运行内的相对比，只是一个取更快的、一个取更慢的——两者的覆盖面相同，故谁都挑不了档位。本节的缺席不构成不合格：分不出胜负或处处更慢时它就应当是空的

对照方案并发度执行体档位（微秒）差距被测框架中位数
apscheduler140被测框架比 apscheduler 快 1.58x182.57 微秒
process_pool140被测框架比 process_pool 快 1.83x182.57 微秒
apscheduler1300被测框架比 apscheduler 快 1.21x449.17 微秒
process_pool1300被测框架比 process_pool 快 1.35x449.17 微秒
apscheduler12700被测框架比 apscheduler 快 1.09x2.754 毫秒
process_pool12700被测框架比 process_pool 快 1.09x2.754 毫秒
apscheduler440被测框架比 apscheduler 快 1.24x206.14 微秒
apscheduler16300被测框架比 apscheduler 快 1.07x470.57 微秒
apscheduler162700被测框架比 apscheduler 快 1.03x2.899 毫秒

数据：被测框架在哪些档位更快

公开的不利数据 · 归类

被测框架在 52 个档位上更慢，来自 5 个对照方案。

apscheduler · 2 个档位更快

最差 1.04x（并发 64 · 10000 微秒）。全部档位：并发 16 · 10000 微秒、并发 64 · 10000 微秒

asyncio_pool · 13 个档位更快

最差 1.72x（并发 64 · 40 微秒）。全部档位：并发 1 · 40 微秒、并发 1 · 300 微秒、并发 1 · 10000 微秒、并发 4 · 300 微秒、并发 4 · 2700 微秒、并发 4 · 10000 微秒、并发 16 · 40 微秒、并发 16 · 300 微秒、并发 16 · 2700 微秒、并发 16 · 10000 微秒、并发 64 · 40 微秒、并发 64 · 300 微秒、并发 64 · 2700 微秒

bare_thread · 13 个档位更快

最差 1.23x（并发 16 · 40 微秒）。全部档位：并发 1 · 300 微秒、并发 1 · 2700 微秒、并发 1 · 10000 微秒、并发 4 · 300 微秒、并发 4 · 2700 微秒、并发 16 · 40 微秒、并发 16 · 300 微秒、并发 16 · 2700 微秒、并发 16 · 10000 微秒、并发 64 · 40 微秒、并发 64 · 300 微秒、并发 64 · 2700 微秒、并发 64 · 10000 微秒

process_pool · 9 个档位更快

最差 2.25x（并发 64 · 10000 微秒）。全部档位：并发 4 · 300 微秒、并发 4 · 2700 微秒、并发 4 · 10000 微秒、并发 16 · 300 微秒、并发 16 · 2700 微秒、并发 16 · 10000 微秒、并发 64 · 300 微秒、并发 64 · 2700 微秒、并发 64 · 10000 微秒

thread_pool · 15 个档位更快

最差 2.41x（并发 1 · 40 微秒）。全部档位：并发 1 · 40 微秒、并发 1 · 300 微秒、并发 1 · 2700 微秒、并发 1 · 10000 微秒、并发 4 · 40 微秒、并发 4 · 300 微秒、并发 4 · 2700 微秒、并发 4 · 10000 微秒、并发 16 · 40 微秒、并发 16 · 300 微秒、并发 16 · 2700 微秒、并发 16 · 10000 微秒、并发 64 · 40 微秒、并发 64 · 300 微秒、并发 64 · 2700 微秒

数据：zoo-bench「公开的不利数据」· 逐档明细见其后的页与 report.md

zoo-bench 报告

公开的不利数据

被测框架处于劣势的档位（两侧差异大于该档位的带宽）。这部分缺失的报告不合格——一份只展示自己赢的报告，读者有理由认为它不可信。差异小于带宽的档位不在本节，而在「分不出胜负」那一节：那是判据的结果，不是把它们藏起来

对照方案并发度执行体档位（微秒）差距被测框架中位数
asyncio_pool140asyncio_pool 比 zoo 快 1.30x182.57 微秒
thread_pool140thread_pool 比 zoo 快 2.41x182.57 微秒
asyncio_pool1300asyncio_pool 比 zoo 快 1.16x449.17 微秒
bare_thread1300bare_thread 比 zoo 快 1.17x449.17 微秒
thread_pool1300thread_pool 比 zoo 快 1.39x449.17 微秒
bare_thread12700bare_thread 比 zoo 快 1.03x2.754 毫秒
thread_pool12700thread_pool 比 zoo 快 1.02x2.754 毫秒
asyncio_pool110000asyncio_pool 比 zoo 快 1.06x10.066 毫秒
bare_thread110000bare_thread 比 zoo 快 1.04x10.066 毫秒
thread_pool110000thread_pool 比 zoo 快 1.08x10.066 毫秒
thread_pool440thread_pool 比 zoo 快 2.15x206.14 微秒

数据：公开的不利数据

公开的不利数据

公开的不利数据（续）

对照方案并发度执行体档位（微秒）差距被测框架中位数
asyncio_pool4300asyncio_pool 比 zoo 快 1.19x485.26 微秒
bare_thread4300bare_thread 比 zoo 快 1.16x485.26 微秒
process_pool4300process_pool 比 zoo 快 1.59x485.26 微秒
thread_pool4300thread_pool 比 zoo 快 1.38x485.26 微秒
asyncio_pool42700asyncio_pool 比 zoo 快 1.07x2.946 毫秒
bare_thread42700bare_thread 比 zoo 快 1.09x2.946 毫秒
process_pool42700process_pool 比 zoo 快 2.13x2.946 毫秒
thread_pool42700thread_pool 比 zoo 快 1.07x2.946 毫秒
asyncio_pool410000asyncio_pool 比 zoo 快 1.02x10.106 毫秒
process_pool410000process_pool 比 zoo 快 2.19x10.106 毫秒
thread_pool410000thread_pool 比 zoo 快 1.03x10.106 毫秒
asyncio_pool1640asyncio_pool 比 zoo 快 1.53x205.75 微秒
bare_thread1640bare_thread 比 zoo 快 1.23x205.75 微秒

数据：公开的不利数据

公开的不利数据

公开的不利数据（续）

对照方案并发度执行体档位（微秒）差距被测框架中位数
thread_pool1640thread_pool 比 zoo 快 2.28x205.75 微秒
asyncio_pool16300asyncio_pool 比 zoo 快 1.20x470.57 微秒
bare_thread16300bare_thread 比 zoo 快 1.11x470.57 微秒
process_pool16300process_pool 比 zoo 快 1.69x470.57 微秒
thread_pool16300thread_pool 比 zoo 快 1.37x470.57 微秒
asyncio_pool162700asyncio_pool 比 zoo 快 1.03x2.899 毫秒
bare_thread162700bare_thread 比 zoo 快 1.07x2.899 毫秒
process_pool162700process_pool 比 zoo 快 2.12x2.899 毫秒
thread_pool162700thread_pool 比 zoo 快 1.05x2.899 毫秒
apscheduler1610000apscheduler 比 zoo 快 1.02x10.084 毫秒
asyncio_pool1610000asyncio_pool 比 zoo 快 1.02x10.084 毫秒
bare_thread1610000bare_thread 比 zoo 快 1.05x10.084 毫秒
process_pool1610000process_pool 比 zoo 快 2.13x10.084 毫秒

数据：公开的不利数据

公开的不利数据

公开的不利数据（续）

对照方案并发度执行体档位（微秒）差距被测框架中位数
thread_pool1610000thread_pool 比 zoo 快 1.03x10.084 毫秒
asyncio_pool6440asyncio_pool 比 zoo 快 1.72x207.28 微秒
bare_thread6440bare_thread 比 zoo 快 1.21x207.28 微秒
thread_pool6440thread_pool 比 zoo 快 2.32x207.28 微秒
asyncio_pool64300asyncio_pool 比 zoo 快 1.28x491.01 微秒
bare_thread64300bare_thread 比 zoo 快 1.16x491.01 微秒
process_pool64300process_pool 比 zoo 快 1.64x491.01 微秒
thread_pool64300thread_pool 比 zoo 快 1.40x491.01 微秒
asyncio_pool642700asyncio_pool 比 zoo 快 1.05x2.953 毫秒
bare_thread642700bare_thread 比 zoo 快 1.10x2.953 毫秒
process_pool642700process_pool 比 zoo 快 2.16x2.953 毫秒
thread_pool642700thread_pool 比 zoo 快 1.10x2.953 毫秒
apscheduler6410000apscheduler 比 zoo 快 1.04x10.538 毫秒

数据：公开的不利数据

公开的不利数据

公开的不利数据（续）

对照方案并发度执行体档位（微秒）差距被测框架中位数
bare_thread6410000bare_thread 比 zoo 快 1.07x10.538 毫秒
process_pool6410000process_pool 比 zoo 快 2.25x10.538 毫秒

数据：公开的不利数据

zoo-bench 报告

分不出胜负的档位

两侧分不出胜负的档位：差异小于该档位的带宽。带宽取自同一次运行内两侧各自的跨轮离散度（每任务中位数的标准差 / 中位数）之和，故它随样本变化，读者可用留档里的逐轮样本自行复核。它同样覆盖全部所测档位、逐项写明原因——本节不是藏东西的地方：把噪声级差异报成「快 1.00x」才是

判据：带宽 = 被测框架侧与对照侧各自的跨轮相对离散度之和；单侧的跨轮相对离散度 = 该单元逐轮的「每任务中位数」的标准差 / 中位数

本期带宽：1.4% 到 30.1%（随各档位的离散度不同而不同）。

对照方案并发度执行体档位（微秒）比值原因
bare_thread1400.82x两侧差异 18.4% 小于带宽 30.1%，分不出胜负
asyncio_pool127001.00x两侧差异 0.1% 小于带宽 3.1%，分不出胜负
apscheduler1100000.99x两侧差异 0.9% 小于带宽 4.6%，分不出胜负
process_pool1100000.98x两侧差异 1.8% 小于带宽 1.9%，分不出胜负
asyncio_pool4400.84x两侧差异 16.1% 小于带宽 17.3%，分不出胜负
bare_thread4400.97x两侧差异 3.0% 小于带宽 14.3%，分不出胜负

数据：分不出胜负的档位

分不出胜负的档位

分不出胜负的档位（续）

对照方案并发度执行体档位（微秒）比值原因
process_pool4400.82x两侧差异 18.1% 小于带宽 22.2%，分不出胜负
apscheduler43001.05x两侧差异 5.3% 小于带宽 7.0%，分不出胜负
apscheduler427001.01x两侧差异 1.3% 小于带宽 2.7%，分不出胜负
apscheduler4100001.02x两侧差异 1.5% 小于带宽 3.2%，分不出胜负
bare_thread4100000.96x两侧差异 4.1% 小于带宽 4.7%，分不出胜负
apscheduler16401.09x两侧差异 8.9% 小于带宽 15.6%，分不出胜负
process_pool16400.73x两侧差异 27.1% 小于带宽 29.0%，分不出胜负
apscheduler64401.07x两侧差异 6.5% 小于带宽 9.9%，分不出胜负
process_pool64400.94x两侧差异 6.4% 小于带宽 16.1%，分不出胜负
apscheduler643001.02x两侧差异 2.2% 小于带宽 5.0%，分不出胜负
apscheduler6427001.00x两侧差异 0.4% 小于带宽 1.7%，分不出胜负
asyncio_pool64100000.99x两侧差异 1.2% 小于带宽 3.9%，分不出胜负
thread_pool64100000.97x两侧差异 2.8% 小于带宽 3.7%，分不出胜负

数据：分不出胜负的档位

zoo-bench 报告

口径局限与偏差来源

  • 被测层级：调度派发层：直接驱动 BaseWaiter.execute_service()（线程池模式），不走 Master 的完整运行循环——后者的服务循环每秒一次，会把延迟量级从微秒抬到秒。每提交一个任务走一次调度轮，故该轮的全部簿记都计在这一个任务头上；Master 的用法是每轮服务多个 worker，那份开销本会摊到多个任务上
  • 口径说明（apscheduler）：APScheduler 的定时作业模型，含作业登记与触发判定成本；该库会吞掉作业内异常，本档已在 drain 时重新抛出。口径说明：该库不提供作业完成通知，故完成信号由本档的 Condition 给出，每任务一次通知的开销计入其端到端
  • 口径说明（asyncio_pool）：asyncio 事件循环调度同步执行体（等价于 loop.run_in_executor），非原生协程并发；与线程池的差别是事件循环自身开销
  • 口径说明（bare_thread）：每任务派生一个 threading.Thread，无池化、无复用；线程创建成本计入端到端。收集执行体自报耗时用无锁的 list.append（GIL 下本身原子）——插桩不得给某一档加别档没有的成本，否则对照就成了插桩的对照
  • 口径说明（process_pool）：ProcessPoolExecutor：执行体与返回值跨进程序列化的成本计入端到端，与多线程档位不可直接等价比较

数据：口径局限与偏差来源

口径局限与偏差来源

口径局限与偏差来源（续）

  • 口径说明（thread_pool）：concurrent.futures.ThreadPoolExecutor，池大小 = 并发度；线程复用、无任务队列语义
  • 口径说明（zoo）：端到端终点为「worker 完成并在飞表注销」；框架其后的结果投递按世代分流：上一代的投递路径是坏的（dispatch 按 reactor_name 而非主题查响应器，每次调用必抛），完成信号只能取自框架内部回调；当前代该处已修好，完成信号取自框架自己的结果响应器。口径说明：完成信号由本档的 Condition 给出，每任务一次通知的开销计入其端到端；该方向的偏差使被测框架看起来更慢，即对被测框架不利而非有利
  • 不给出开销数字的组：以下 (适配器, 并发度) 组的并发度超过这次运行所在机器的并行能力：执行体自报的耗时里含超订带来的调度等待，与「墙钟 / 并发度」不是同一件事，相减的结果没有意义（实测出现过负值，并衍生出无意义的变化倍数）。故本报告对它们不给框架开销、也不给交叉点；端到端、吞吐与执行体自报值仍然有效，原始留档里的字段也一个没删。判据取自环境自述的逻辑核数，另有一条证据性兜底：算出来的开销为负同样判为不可读——框架只会加时间不会减时间
  • 原生任务线：未出结论：原生任务线结论为 not_applicable（被测框架不具备该能力（找不到这些符号：adaptive_params, dual_arm_worker, native_params, native_task_worker）——该线对此版本不适用，这不是失败）、未产出任何数字。它记在这里而不是并入自检：一条线的失败不得拖住其余版本的数据与主矩阵

数据：口径局限与偏差来源

口径局限与偏差来源

本章其余明细在全文里

幻灯片为了「一页一个结论」只放了本章的前 2 页；余下 1 页的逐单元数值、分位数与原始样本都在全文的同一章节里，逐字可核。

全文：同目录 report.md 的「口径局限与偏差来源」章节

zoo-bench 报告

加入你自己的对照

本 harness 的对照方案是开放的：实现 zoo_bench.adapters.BaseAdapter 的四个方法（setup / submit / drain / teardown），用 zoo_bench.adapters.registry.register 登记，或在 matrix.yaml 的 extra_modules 里列出你的模块路径——无需改动本仓库任何文件。你的实现会通过同一套等价性验证（提交 N 个执行体、断言全部执行且各执行一次），不通过的不会被采信。我们主动把这条路径写进报告：一份由被测框架维护者撰写、测量被测框架的报告，读者有理由怀疑对照被写慢或口径被挑选；让任何人能提交自己的对照，是这份报告可被质疑、也可被证伪的前提。

数据：加入你自己的对照

zoo-bench 报告

自检

  • 测量自检整体：通过
  • 进程隔离：{'parent_pid': 43405, 'child_pids': [43869, 43872, 43875, 43878, 43881, 43887, 43893, 43899, 43905, 43923, 43941, 43959, 43978, 44034, 44090, 44145, 44206, 44208, 44210, 44212, 44214, 44219, 44224, 44229, 44234, 44251, 44268, 44285, 44302, 44363, 44425, 44490, 44555, 44589, 44623, 44657, 44691, 44824, 44959, 45092, 45225, 45754, 46283, 46812, 47341, 49454, 51567, 53680, 55794, 55798, 55802, 55806, 55810, 55817, 55824, 55831, 55838, 55857, 55876, 55895, 55914, 55981, 56048, 56115, 56182, 56184, 56186, 56189, 56191, 56196, 56201, 56206, 56211, 56228, 56245, 56262, 56279, 56335, 56392, 56453, 56519, 56521, 56523, 56525, 56527, 565
  • 32, 56537, 56542, 56547, 56564, 56581, 56598, 56615, 56664, 56713, 56758], 'all_distinct': True, 'none_equals_parent': True}

数据：自检

附录

每一页都可在全文里逐字复核

幻灯片为了「一页一个结论」而压缩了篇幅；被压缩的只有排版，没有数值。

  • 逐单元明细（分位数、离散度、每轮原始样本）：同目录的 report.md
  • 图表（SVG 与 PNG）：同目录的 figures/，另见 report.pdf
  • 原始留档：results/zoo-framework-0.9.0/20261011T092749Z.json
  • 本轮有效单元 96，失败单元 0

明细有一百多行，压进幻灯片等于让读者失去核对的手段。

← / → · space · R reset