外部基线对比（scalim vs pandas / polars 惯用法）¶

版本锚定：scalim 0.10.3（local src）/ pandas 2.3.3 / polars 1.42.1 / openpyxl 3.1.5 / Python 3.10.18。
两侧外部库取惯用法（DataFrame 全量物化 + 向量化派生 + 库内写出）；scalim 侧测 seq 与 adaptive(max_workers=4) 两种模式。
本页只回答一个问题：在你熟悉的写法面前，scalim 的时间/内存处于什么位置、什么时候不占优。

数据文件（可复用，含全部 108 run 明细）：assets/data/external-baseline-0.10.json。

术语与缩写对照（图表通用）¶

1. Shapes：七种典型表¶

2. 结果总表（median；时间比/内存比均以 pandas 为 1.0）¶

短耗时 shape（S3/S4/S7）跑 5 次取 median；其余 3 次。108/108 golden 通过；全部 run 峰值在内存预算内（最大 1.86 GiB）。

3. 读法（诚实版）¶

3.1 内存轴：scalim 全场断层领先，且与表面积无关¶

flowchart LR
  A["pandas / polars<br/>全量物化"] -->|"0.12–1.86 GiB<br/>随 cells/rows 线性涨"| B[峰值 ∝ 表面积]
  C["scalim<br/>批次流式 + 释放 + write_only"] -->|"30–56 MiB 平台"| D[峰值与形状无关]

• scalim 峰值 RSS 在 0.74M–15.5M cells 全区间保持 30–56 MiB 平台（覆盖 S1–S6 全部形状）
• 对 pandas：峰值 1/3.8（S7）～ 1/35（S6）；对 polars：1/7（S3）～ 1/37（S4）
• polars 内存并不总是更低：csv 大导出（S2/S4/S5）与关联（S7）场景，polars 峰值反而高于 pandas（1.3×–3.3×）；仅 xlsx 场景优于 pandas（0.8×）

3.2 时间轴：polars 全场最快；scalim 的位置分场景¶

3.3 adaptive：单 demand 报表形状下 ≈ seq¶

S1–S7 全部形状 adaptive 与 seq 差异在噪声内（±4%）。这类「单一数据流 + 派生链」demand 没有可识别的并行机会，adaptive 不带来收益也不劣化；其收益场景是多个独立任务/源的 fan-out/fan-in 编排，不在本矩阵范围。

3.4 选型暗示¶

4. 补充证据（交互图表）¶

以下图表由数据 JSON 实时渲染；口径与 §2 一致。图表术语见页首「术语与缩写对照」。

4.1 扫参曲线：峰值内存与行数/列数的关系¶

固定 20 个派生列、行数从 1k 扫到 1M（csv）；或固定 1 万行、派生列从 5 扫到 600（csv）。 看两个事实：scalim 的内存线是不是一条平线；另外两家随表面积涨多快。

怎么读（官方数字）：

• 行数轴：pandas 峰值 111 → 499 MiB（每 100 万行约 +390 MiB）；polars 起点 343 → 1M 行 775 MiB；scalim 全程 29.8–30.2 MiB 一条平线（1k 行与 1M 行完全一致）。
• 列数轴（1 万行）：pandas 116 → 212 MiB；polars 平稳在 410–470 MiB（起手就高）；scalim 30.1 → 32.4 MiB（600 列仅 +2.3）。
• 结论：「峰值内存 ∝ 表面积」对全量物化两家都成立；scalim 的峰值与表面积无关。

时间轴（同口径，看三侧的斜率差异；csv 场景 polars 最快、scalim 最慢，与 §3.2 一致）：

4.2 派生函数变重后会怎样¶

派生函数从「一行算术」（L0）加重到「十次循环」（L1）、「百次循环」（L2）。 pandas/polars 的向量化只对 L0 有效；L1/L2 属于「逻辑不可向量化」，惯用写法是 apply/map_elements 逐行执行 Python 函数。 预期：函数越重，框架开销占比越小，三侧时间差越窄。

怎么读（官方数字，10k 行 × 20 派生列，总耗时秒）：

• 交叉点在 L0→L1 之间：业务逻辑一旦不可向量化，pandas 的 apply 反而比 scalim 慢 3 倍；polars 的 map_elements 始终最快但内存仍是 scalim 的 13 倍以上。
• 这验证了 §3.4 非保证边界的前半句「重计算会缩小时间差」——实测不仅缩小，还会反转。

4.3 慢源关联：分片并行（keys 模式）¶

模拟「向远端源做 2 万个键的关联查询，每次往返 RTT 毫秒级」： 全量单次拉取（1 次请求，要求 side 表能整表放内存）vs 分片串行 vs 分片并行（W=4）。

怎么读（官方数字，总耗时秒）：

• 分片并行对串行分片提速约 3–7×（W=4 下近似 ÷W，与 lookup chunk 并行 的 3.3–6.4× 相符）。
• 全量单次最快——前提是 side 表能整表放进内存、且服务端接受大 IN 请求。分片并行的适用前提是「side 表拉不动 / 接口有分页上限」，此时它是唯一能既流式又并行的方式。

4.4 Python 3.6 最低兼容边界（0.10 历史；0.20 起 floor 为 3.10）¶

官方测量环境是 3.10；本节为 0.10 线的历史测量（0.10 曾支持 Python 3.6，0.20 起支持窗口收敛为 3.10+，见根 ROADMAP.md），保留用于历史行为对照： 同一份 3.6 兼容的 runner 在 docker python:3.6.15 与宿主 3.10 各跑同 shape（csv，串行），口径同上。

怎么读（官方数字，median）：

• 功能与正确性一致（golden 全过），峰值内存同量级甚至略低，时间约 1.3–1.5×（解释器代差，预期内）。
• 结论（历史）：0.10 在其最低兼容 3.6 下的内存主张与正确性不依赖高版本 Python。0.20 起不再承诺 3.6。

5. 复现¶

复现脚本（已入库）：docs/doc/releases/repro/external-baseline/run_ab.py。测量环境需 Python 3.10+（pandas/polars 依赖）。

# 冒烟（缩放 5%，~1 分钟）
just bench-external --runs 1 --rows-scale 0.05

# 完整官方测量（7 shapes × 4 配置 × 3/5 runs，约 25–40 分钟；产物在 .tmp/ 不入库）
just bench-external --runs 3

# 扩展证据探针（扫参 / 函数复杂度 / 慢源分片并行 / py36 边界；约 20–30 分钟）
just bench-external-probes --runs 3

刷新约定：minor 版本发布前用 just bench-external 与 just bench-external-probes 官方重测一次，同步更新本页、数据 JSON 与 README 性能小节。

6. 引用规范（写给维护者与 agent）¶

对外引用本页数字时 MUST 同时携带：版本锚定（scalim 0.10.3 / pandas 2.3.3 / polars 1.42.1）、workload 形状、环境与运行次数（3/5 次 median）、正确性对拍声明（golden）、以及 §3.4 非保证边界。MUST NOT 将其表述为通用加速、真实业务基准或跨机器 SLA（与 governance-readme-examples r986 一致）。