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

zoo-framework 0.10.0
性能评测

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

原始数据：results/zoo-framework-0.10.0/20261011T093201Z.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.10.0
被测框架（模块 __version__）0.10.0（仅附注，不作版本判据）
被测框架的驱动面世代当前代驱动面（调度内核 core + 调度模型 model，完成信号取自结果响应器）
harnesszoo-bench 0.0.1 @ 9a42be24ac43f75e2e5d7b16434f91ba3d0717b6
复现命令zoo-bench run --framework zoo-framework==0.10.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 快 2.11x（该并发度所测档位中最快的一档）。
  • 并发度 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 下，执行体时长超过约 10000 微秒 后，bare_thread 不再快于被测框架。
  • 并发度 4 下，所测档位内 bare_thread 始终快于被测框架——这类档位正是本报告的公开不利数据。
  • 并发度 16 下，执行体时长超过约 40 微秒 后，bare_thread 不再快于被测框架。
  • 并发度 64 下，所测档位内 bare_thread 始终快于被测框架——这类档位正是本报告的公开不利数据。

数据：结论摘要

结论摘要

本章其余明细在全文里

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

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

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

1.81%

执行体 10000 微秒 时，zoo 的框架自身开销占比。
该档位有 3 个方案更低：asyncio_pool、bare_thread、thread_pool。
同档对比：apscheduler 4.13%、asyncio_pool 1.41%、bare_thread 1.26%、process_pool 3.64%、thread_pool 0.60%

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

维度：延迟分位数与抖动

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

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

执行体 40 微秒
zoo
157.73 微秒
apscheduler
288.55 微秒
asyncio_pool
140.57 微秒
bare_thread
141.79 微秒
process_pool
332.18 微秒
thread_pool
83.56 微秒
执行体 300 微秒
zoo
424.91 微秒
apscheduler
547.57 微秒
asyncio_pool
404.67 微秒
bare_thread
405.40 微秒
process_pool
606.50 微秒
thread_pool
323.16 微秒
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

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

维度：延迟分位数与抖动

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

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

执行体 2700 微秒
zoo
2.797 毫秒
apscheduler
3.120 毫秒
asyncio_pool
2.605 毫秒
bare_thread
2.717 毫秒
process_pool
3.017 毫秒
thread_pool
2.667 毫秒
执行体 10000 微秒
zoo
9.931 毫秒
apscheduler
9.890 毫秒
asyncio_pool
9.476 毫秒
bare_thread
9.972 毫秒
process_pool
10.015 毫秒
thread_pool
9.618 毫秒
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

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

zoo-bench 报告

维度：延迟分位数与抖动

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

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
140157.73 微秒288.55 微秒140.57 微秒141.79 微秒332.18 微秒83.56 微秒
1300424.91 微秒547.57 微秒404.67 微秒405.40 微秒606.50 微秒323.16 微秒
127002.797 毫秒3.120 毫秒2.605 毫秒2.717 毫秒3.017 毫秒2.667 毫秒
1100009.931 毫秒9.890 毫秒9.476 毫秒9.972 毫秒10.015 毫秒9.618 毫秒
440183.23 微秒253.08 微秒159.80 微秒162.08 微秒188.60 微秒94.96 微秒
4300439.01 微秒519.95 微秒410.40 微秒409.00 微秒295.22 微秒362.52 微秒
427002.848 毫秒3.035 毫秒2.749 毫秒2.659 毫秒1.398 毫秒2.706 毫秒
41000010.050 毫秒10.021 毫秒9.977 毫秒9.793 毫秒4.598 毫秒9.798 毫秒
1640170.72 微秒251.40 微秒138.08 微秒174.45 微秒160.88 微秒90.52 微秒
16300439.04 微秒501.69 微秒394.14 微秒430.66 微秒280.12 微秒351.18 微秒
1627002.926 毫秒2.952 毫秒2.822 毫秒2.724 毫秒1.395 毫秒2.718 毫秒

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

维度：延迟分位数与抖动

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

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
161000010.507 毫秒10.271 毫秒9.992 毫秒9.834 毫秒4.711 毫秒10.001 毫秒
6440184.98 微秒224.83 微秒123.94 微秒169.50 微秒195.74 微秒89.55 微秒
64300472.05 微秒505.68 微秒373.95 微秒424.17 微秒297.44 微秒349.61 微秒
6427002.937 毫秒2.974 毫秒2.777 毫秒2.722 毫秒1.417 毫秒2.768 毫秒
641000010.515 毫秒10.311 毫秒10.449 毫秒9.812 毫秒4.709 毫秒10.022 毫秒

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

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

维度：框架自身开销占比

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

并发度 1 · 框架自身开销

执行体 40 微秒
zoo
67.93%
apscheduler
82.14%
asyncio_pool
66.96%
bare_thread
63.81%
process_pool
82.88%
thread_pool
38.45%
执行体 300 微秒
zoo
28.57%
apscheduler
44.63%
asyncio_pool
26.17%
bare_thread
28.08%
process_pool
50.03%
thread_pool
10.75%
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

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

维度：框架自身开销占比

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

并发度 1 · 框架自身开销

执行体 2700 微秒
zoo
5.17%
apscheduler
9.74%
asyncio_pool
4.50%
bare_thread
4.20%
process_pool
11.29%
thread_pool
1.80%
执行体 10000 微秒
zoo
1.81%
apscheduler
4.13%
asyncio_pool
1.41%
bare_thread
1.26%
process_pool
3.64%
thread_pool
0.60%
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

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

zoo-bench 报告

维度：框架自身开销占比

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

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
14067.93%82.14%66.96%63.81%82.88%38.45%
130028.57%44.63%26.17%28.08%50.03%10.75%
127005.17%9.74%4.50%4.20%11.29%1.80%
1100001.81%4.13%1.41%1.26%3.64%0.60%
44072.88%77.73%66.65%68.11%49.63%47.40%
430031.79%40.54%25.54%27.64%—15.92%
427005.27%9.67%4.68%4.32%—3.15%
410000——————
1640——————
16300——————
162700——————

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

维度：框架自身开销占比

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

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

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

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

维度：吞吐与并发伸缩

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

并发度 1 · 吞吐

执行体 40 微秒
zoo
6,340 任务/秒
apscheduler
3,466 任务/秒
asyncio_pool
7,114 任务/秒
bare_thread
7,053 任务/秒
process_pool
3,010 任务/秒
thread_pool
11,967 任务/秒
执行体 300 微秒
zoo
2,353 任务/秒
apscheduler
1,826 任务/秒
asyncio_pool
2,471 任务/秒
bare_thread
2,467 任务/秒
process_pool
1,649 任务/秒
thread_pool
3,094 任务/秒
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

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

维度：吞吐与并发伸缩

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

并发度 1 · 吞吐

执行体 2700 微秒
zoo
358 任务/秒
apscheduler
321 任务/秒
asyncio_pool
384 任务/秒
bare_thread
368 任务/秒
process_pool
331 任务/秒
thread_pool
375 任务/秒
执行体 10000 微秒
zoo
101 任务/秒
apscheduler
101 任务/秒
asyncio_pool
106 任务/秒
bare_thread
100 任务/秒
process_pool
100 任务/秒
thread_pool
104 任务/秒
被测框架对照方案条形 = 相对被测框架的倍数，1.0 为持平，越长越差

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

zoo-bench 报告

维度：吞吐与并发伸缩

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

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
1406340.13465.77114.07052.93010.411967.2
13002353.51826.22471.22466.71648.83094.4
12700357.6320.5383.9368.0331.4374.9
110000100.7101.1105.5100.399.9104.0
44021830.715805.125031.024678.821208.842122.3
43009111.47693.19746.59780.013549.011034.0
427001404.61317.91455.11504.02861.81478.5
410000398.0399.2400.9408.4869.9408.3
164093723.063644.3115870.791714.499452.7176759.3
1630036443.431892.440594.737152.457119.045560.6
1627005468.75419.35670.25873.411467.35885.6

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

维度：吞吐与并发伸缩

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

并发度执行体档位（微秒）zooapschedulerasyncio_poolbare_threadprocess_poolthread_pool
16100001522.81557.71601.31626.93396.21599.9
6440345987.8284656.4516381.4377578.2326969.3714659.3
64300135579.6126561.3171144.5150881.9215170.2183061.8
64270021794.521519.823045.623513.045160.723119.9
64100006086.66207.06125.16522.613591.76385.7

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

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

zoo-bench 报告

维度：开销归因

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

状态：ok

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

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

方案并发度档位（微秒）提交侧手交执行体回程状态
apscheduler140110.01 微秒83.43 微秒58.01 微秒43.81 微秒ok
apscheduler440101.53 微秒508.15 微秒56.80 微秒221.34 微秒ok
apscheduler110000168.54 微秒113.17 微秒9.639 毫秒63.68 微秒ok

数据：维度：开销归因

维度：开销归因

维度：开销归因（续）

方案并发度档位（微秒）提交侧手交执行体回程状态
apscheduler410000132.04 微秒10.592 毫秒14.575 毫秒9.825 毫秒ok
asyncio_pool14017.04 微秒26.12 微秒49.00 微秒58.29 微秒ok
asyncio_pool44019.30 微秒249.31 微秒55.20 微秒304.58 微秒ok
asyncio_pool11000026.82 微秒41.45 微秒9.214 毫秒93.47 微秒ok
asyncio_pool41000023.10 微秒12.397 毫秒9.982 毫秒10.142 毫秒ok
bare_thread140146.55 微秒-77.58 微秒52.32 微秒32.58 微秒ok
bare_thread440155.98 微秒-75.15 微秒51.04 微秒317.86 微秒ok
bare_thread1100005.184 毫秒-5093.18 微秒9.592 毫秒41.48 微秒ok
bare_thread4100005.212 毫秒-5085.74 微秒14.658 毫秒9.873 毫秒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.0123s）（执行体 0.15s、run_timeout 0.01s）；判定动作在 dispatch_core.py:427；生效的是观测与熔断（记录、标记不健康、摘除在飞登记、停止派发），不是终止仍在执行的 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.83x157.73 微秒
process_pool140被测框架比 process_pool 快 2.11x157.73 微秒
apscheduler1300被测框架比 apscheduler 快 1.29x424.91 微秒
process_pool1300被测框架比 process_pool 快 1.43x424.91 微秒
apscheduler12700被测框架比 apscheduler 快 1.12x2.797 毫秒
process_pool12700被测框架比 process_pool 快 1.08x2.797 毫秒
apscheduler440被测框架比 apscheduler 快 1.38x183.23 微秒
apscheduler4300被测框架比 apscheduler 快 1.18x439.01 微秒
apscheduler42700被测框架比 apscheduler 快 1.07x2.848 毫秒
apscheduler1640被测框架比 apscheduler 快 1.47x170.72 微秒
apscheduler16300被测框架比 apscheduler 快 1.14x439.04 微秒

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

被测框架在哪些档位更快

被测框架在哪些档位更快（续）

对照方案并发度执行体档位（微秒）差距被测框架中位数
apscheduler6440被测框架比 apscheduler 快 1.22x184.98 微秒

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

公开的不利数据 · 归类

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

asyncio_pool · 8 个档位更快

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

bare_thread · 8 个档位更快

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

process_pool · 9 个档位更快

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

thread_pool · 16 个档位更快

最差 2.07x（并发 64 · 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 微秒、并发 64 · 10000 微秒

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

zoo-bench 报告

公开的不利数据

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

对照方案并发度执行体档位（微秒）差距被测框架中位数
thread_pool140thread_pool 比 zoo 快 1.89x157.73 微秒
thread_pool1300thread_pool 比 zoo 快 1.31x424.91 微秒
asyncio_pool12700asyncio_pool 比 zoo 快 1.07x2.797 毫秒
bare_thread12700bare_thread 比 zoo 快 1.03x2.797 毫秒
thread_pool12700thread_pool 比 zoo 快 1.05x2.797 毫秒
thread_pool110000thread_pool 比 zoo 快 1.03x9.931 毫秒
thread_pool440thread_pool 比 zoo 快 1.93x183.23 微秒
asyncio_pool4300asyncio_pool 比 zoo 快 1.07x439.01 微秒
bare_thread4300bare_thread 比 zoo 快 1.07x439.01 微秒
process_pool4300process_pool 比 zoo 快 1.49x439.01 微秒
thread_pool4300thread_pool 比 zoo 快 1.21x439.01 微秒

数据：公开的不利数据

公开的不利数据

公开的不利数据（续）

对照方案并发度执行体档位（微秒）差距被测框架中位数
asyncio_pool42700asyncio_pool 比 zoo 快 1.04x2.848 毫秒
bare_thread42700bare_thread 比 zoo 快 1.07x2.848 毫秒
process_pool42700process_pool 比 zoo 快 2.04x2.848 毫秒
thread_pool42700thread_pool 比 zoo 快 1.05x2.848 毫秒
process_pool410000process_pool 比 zoo 快 2.19x10.050 毫秒
thread_pool410000thread_pool 比 zoo 快 1.03x10.050 毫秒
thread_pool1640thread_pool 比 zoo 快 1.89x170.72 微秒
asyncio_pool16300asyncio_pool 比 zoo 快 1.11x439.04 微秒
process_pool16300process_pool 比 zoo 快 1.57x439.04 微秒
thread_pool16300thread_pool 比 zoo 快 1.25x439.04 微秒
asyncio_pool162700asyncio_pool 比 zoo 快 1.04x2.926 毫秒
bare_thread162700bare_thread 比 zoo 快 1.07x2.926 毫秒
process_pool162700process_pool 比 zoo 快 2.10x2.926 毫秒

数据：公开的不利数据

公开的不利数据

公开的不利数据（续）

对照方案并发度执行体档位（微秒）差距被测框架中位数
thread_pool162700thread_pool 比 zoo 快 1.08x2.926 毫秒
asyncio_pool1610000asyncio_pool 比 zoo 快 1.05x10.507 毫秒
bare_thread1610000bare_thread 比 zoo 快 1.07x10.507 毫秒
process_pool1610000process_pool 比 zoo 快 2.23x10.507 毫秒
thread_pool1610000thread_pool 比 zoo 快 1.05x10.507 毫秒
thread_pool6440thread_pool 比 zoo 快 2.07x184.98 微秒
asyncio_pool64300asyncio_pool 比 zoo 快 1.26x472.05 微秒
bare_thread64300bare_thread 比 zoo 快 1.11x472.05 微秒
process_pool64300process_pool 比 zoo 快 1.59x472.05 微秒
thread_pool64300thread_pool 比 zoo 快 1.35x472.05 微秒
asyncio_pool642700asyncio_pool 比 zoo 快 1.06x2.937 毫秒
bare_thread642700bare_thread 比 zoo 快 1.08x2.937 毫秒
process_pool642700process_pool 比 zoo 快 2.07x2.937 毫秒

数据：公开的不利数据

公开的不利数据

公开的不利数据（续）

对照方案并发度执行体档位（微秒）差距被测框架中位数
thread_pool642700thread_pool 比 zoo 快 1.06x2.937 毫秒
bare_thread6410000bare_thread 比 zoo 快 1.07x10.515 毫秒
process_pool6410000process_pool 比 zoo 快 2.23x10.515 毫秒
thread_pool6410000thread_pool 比 zoo 快 1.05x10.515 毫秒

数据：公开的不利数据

zoo-bench 报告

分不出胜负的档位

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

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

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

对照方案并发度执行体档位（微秒）比值原因
asyncio_pool1400.89x两侧差异 10.9% 小于带宽 19.3%，分不出胜负
bare_thread1400.90x两侧差异 10.1% 小于带宽 16.8%，分不出胜负
asyncio_pool13000.95x两侧差异 4.8% 小于带宽 9.9%，分不出胜负
bare_thread13000.95x两侧差异 4.6% 小于带宽 9.8%，分不出胜负
apscheduler1100001.00x两侧差异 0.4% 小于带宽 1.3%，分不出胜负
asyncio_pool1100000.95x两侧差异 4.6% 小于带宽 6.3%，分不出胜负

数据：分不出胜负的档位

分不出胜负的档位

分不出胜负的档位（续）

对照方案并发度执行体档位（微秒）比值原因
bare_thread1100001.00x两侧差异 0.4% 小于带宽 1.0%，分不出胜负
process_pool1100001.01x两侧差异 0.8% 小于带宽 1.3%，分不出胜负
asyncio_pool4400.87x两侧差异 12.8% 小于带宽 17.9%，分不出胜负
bare_thread4400.88x两侧差异 11.5% 小于带宽 13.1%，分不出胜负
process_pool4401.03x两侧差异 2.9% 小于带宽 26.2%，分不出胜负
apscheduler4100001.00x两侧差异 0.3% 小于带宽 2.1%，分不出胜负
asyncio_pool4100000.99x两侧差异 0.7% 小于带宽 1.6%，分不出胜负
bare_thread4100000.97x两侧差异 2.6% 小于带宽 3.9%，分不出胜负
asyncio_pool16400.81x两侧差异 19.1% 小于带宽 22.7%，分不出胜负
bare_thread16401.02x两侧差异 2.2% 小于带宽 18.1%，分不出胜负
process_pool16400.94x两侧差异 5.8% 小于带宽 33.0%，分不出胜负
bare_thread163000.98x两侧差异 1.9% 小于带宽 6.6%，分不出胜负
apscheduler1627001.01x两侧差异 0.9% 小于带宽 2.0%，分不出胜负

数据：分不出胜负的档位

分不出胜负的档位

本章其余明细在全文里

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

全文：同目录 report.md 的「分不出胜负的档位」章节

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': 56883, 'child_pids': [57338, 57341, 57344, 57347, 57350, 57356, 57362, 57368, 57375, 57393, 57411, 57429, 57447, 57505, 57563, 57620, 57688, 57690, 57692, 57694, 57696, 57701, 57706, 57711, 57716, 57733, 57750, 57768, 57789, 57849, 57908, 57973, 58040, 58074, 58108, 58142, 58176, 58309, 58442, 58575, 58708, 59237, 59766, 60296, 60825, 62938, 65051, 67164, 69280, 69284, 69288, 69292, 69296, 69303, 69310, 69317, 69324, 69343, 69362, 69381, 69400, 69467, 69535, 69603, 69670, 69672, 69674, 69676, 69678, 69683, 69688, 69693, 69698, 69715, 69732, 69749, 69766, 69822, 69879, 69940, 70005, 70007, 70009, 70011, 70013, 700
  • 18, 70023, 70028, 70033, 70050, 70067, 70084, 70102, 70167, 70232, 70297], 'all_distinct': True, 'none_equals_parent': True}

数据：自检

附录

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

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

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

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

← / → · space · R reset