Python：DataFrame 行处理 5 倍加速：GIL 版多线程反而退化的对照组

一、问题的起点：为什么“多线程”会成为负优化

在数据处理的日常里，有一类需求天然带着“逐行”的味道：根据一行里的多个字段做条件分支、调用外部规则引擎、拼接字符串、做正则清洗、写日志、算一个依赖上下文的滚动指标。用 pandas 写出来往往就是 df.iterrows() 或 df.apply(..., axis=1)。当数据量从十万涨到千万，脚本从几秒变成几十分钟，工程师的第一反应通常是：这是 CPU 密集，那就上多线程。

结果往往令人困惑：单线程 100 秒的任务，开了 8 个线程之后变成 130 秒甚至 200 秒。CPU 利用率没有上去，内存占用却翻了几倍，日志里还夹杂着 GIL 争抢带来的抖动。这不是玄学，而是 CPython 运行时的一个确定性结果。本文评述：把“多线程”当作 CPU 密集任务的默认加速手段，是 Python 性能优化中最常见、也最昂贵的认知误区之一。

要理解这个现象，需要先把问题拆成三层：解释器层的并发模型（GIL）、数据结构层的内存布局（pandas BlockManager 与对象数组）、算法层的语义表达（逐行 vs 列式）。这三层是乘法关系，任何一层没处理好，另外两层的优化都会被吃掉。本文的主线正是这条“三层乘积”模型。

一个经验判据：如果一段代码在单线程下 CPU 利用率只有 100%（单核跑满），且热点在 Python 字节码层面，那么加线程几乎必然退化；如果热点在释放 GIL 的 C 扩展里（如 NumPy、zlib、hashlib），加线程才可能线性扩展。

二、GIL 的真实语义：它到底锁住了什么

2.1 GIL 不是“锁住整个程序”

全局解释器锁（Global Interpreter Lock，GIL）是 CPython 实现中的一个互斥量，它保证同一时刻只有一个线程在执行 Python 字节码。注意限定词：Python 字节码。当线程进入一个不操作 Python 对象的 C 扩展函数时，它可以主动释放 GIL，让其他线程继续跑字节码。NumPy 的大量 ufunc、zlib.compress、hashlib 的部分实现都属于这一类。

这解释了一个经典现象：多线程做 NumPy 矩阵乘法可能有效，多线程做 iterrows() 一定无效。因为后者每一步都在创建 Python 对象、调用 Python 层方法、执行字节码，GIL 从头到尾被高频持有与释放。

2.2 切换成本：不只是“排队”

CPython 的 GIL 采用“强制释放 + 竞争重取”的策略。旧版本依赖字节码计数（sys.setswitchinterval 控制时间片，默认 5ms），新版本在 3.10 之后引入了更细的调度改进。但无论版本如何，线程在争抢 GIL 时会发生：

• 上下文切换：保存/恢复寄存器、栈、缓存局部性被破坏；
• 唤醒延迟：被唤醒的线程不一定立刻拿到 GIL，存在“护航效应”（convoy effect）；
• 缓存抖动：多核之间缓存行来回失效，L1/L2 命中率下降。

David Beazley 在 PyCon 2010 的经典演讲《Understanding the Python GIL》中用可视化方式展示了这种抖动：在 CPU 密集的纯 Python 代码上，双线程的吞吐甚至低于单线程。这一结论在后续多个版本中被反复验证，本文评述：GIL 的代价不是“不能并行”，而是“并行的调度成本高于收益”，这正是对照组实验要量化的东西。

2.3 自由线程（Free-threaded）进展

PEP 703 提出了移除 GIL 的长期方案，Python 3.13 起提供了实验性的 free-threaded 构建（--disable-gil），并配套 PEP 659 的自适应解释器与偏向引用计数等机制。需要清醒认识的是：自由线程解决的是“能否并行”，不解决“逐行语义本身昂贵”。即使 GIL 消失，iterrows 里每行创建 Series 的开销依然存在。这一点是本文主线的重要推论。

三、行处理的成本解剖：一次 iterrows 到底做了什么

3.1 iterrows 的隐藏动作

很多人以为 for idx, row in df.iterrows() 只是“取一行”。实际上每次迭代至少发生：

1. 从 BlockManager 中按行切片，构造一个新的 Series 对象；
2. 为这个 Series 建立索引对象（Index）与 dtype 推断；
3. 若列存在混合 dtype，可能触发向上转型（upcast）；
4. Python 层循环变量绑定、属性访问、方法查找；
5. 迭代结束后对象进入 GC 周期，产生回收压力。

pandas 官方文档在 “Iterating through rows” 一节中明确建议：iterrows 在多数场景下应被视为最后手段，并推荐 itertuples、向量化或 NumPy 数组。本文评述：iterrows 的本质是“把列式存储强行转成行式对象”，这是一次结构性逆操作，成本天然高。

3.2 内存布局视角：为什么列式存储讨厌行访问

pandas 底层是列式（column-major）的 BlockManager：同一 dtype 的列被放在连续的 NumPy 数组里。行访问意味着跨多个数组做“步进式”读取，缓存局部性差。相比之下，列操作是连续内存扫描，能吃到 SIMD 与预取红利。

访问模式	内存局部性	典型实现	相对成本
整列运算	连续扫描，优	NumPy ufunc / Arrow kernel	1×
itertuples	元组，中等	namedtuple 迭代	3–8×
apply(axis=1)	构造 Series，差	逐行 Series + 函数调用	10–50×
iterrows	构造 Series + Index，最差	逐行 Series 重建	15–80×

注：上表相对成本为整合数据，综合 pandas 官方文档建议与社区基准（如 pandas 文档 “Enhancing performance”、Stack Overflow 高赞基准帖）整理，仅用于量级示意，非单一实验精确值。

四、对照组实验设计：可复现的基准测试方法

4.1 为什么要“对照组”

性能文章最容易犯的错是只给“优化后很快”，不给“优化前多慢”和“错误优化多慢”。本文主张三段式对照：基线（单线程 iterrows）→ 错误优化（GIL 多线程）→ 正确优化（向量化/多进程/编译）。只有把“负优化”也量化，结论才可信。

4.2 基准脚本骨架

import time, numpy as np, pandas as pd
from concurrent.futures import ThreadPoolExecutor

def make_df(n=200_000, seed=42):
    rng = np.random.default_rng(seed)
    return pd.DataFrame({
        "a": rng.normal(size=n),
        "b": rng.integers(0, 100, size=n),
        "c": rng.choice(["x", "y", "z"], size=n),
    })

def row_fn(r):
    # 故意写成语义上“必须逐行”的形态，用于对照
    if r["b"] % 7 == 0:
        return r["a"] * 2 + len(r["c"])
    return r["a"] - r["b"]

def baseline(df):
    return [row_fn(r) for _, r in df.iterrows()]

def threaded(df, workers=8):
    chunks = np.array_split(df, workers)
    with ThreadPoolExecutor(workers) as ex:
        parts = list(ex.map(baseline, chunks))
    return [x for p in parts for x in p]

if __name__ == "__main__":
    df = make_df()
    for name, fn in [("baseline", baseline), ("threaded", threaded)]:
        t = time.perf_counter(); fn(df); dt = time.perf_counter() - t
        print(f"{name}: {dt:.2f}s")

这段脚本的价值不在“跑出某个数”，而在于它把对照组固定下来：同样的 row_fn、同样的数据、只改并发模型。笔者认为，任何性能结论如果不附带可复现脚本与硬件信息，都只能当作轶事，不能当作证据。

4.3 测量规范

• 用 time.perf_counter() 而非 time.time()；
• 每档至少 5 次取中位数，丢弃首次（含 JIT/缓存预热）；
• 固定 CPU 频率、关闭其他重负载进程；
• 记录 Python 版本、pandas/NumPy 版本、CPU 型号、内存带宽；
• 区分 wall time 与 CPU time，多线程退化常表现为 wall 上升而 CPU 总时间暴涨。

五、第一层优化：向量化与语义重写

5.1 把“逐行 if”翻译成 np.where / np.select

上面的 row_fn 完全可以列式表达：

cond = (df["b"] % 7 == 0)
out = np.where(cond, df["a"] * 2 + df["c"].str.len(), df["a"] - df["b"])

多分支用 np.select：

conds = [(df["b"] < 30), (df["b"] < 70), (df["b"] >= 70)]
choices = [df["a"] * 2, df["a"] + 1, df["a"] - 1]
out = np.select(conds, choices, default=0.0)

本文评述：向量化的本质不是“换个 API”，而是把控制流从解释器搬到编译好的内核里。一旦控制流进入 NumPy/C 层，GIL 的讨论就退居次要——因为热点已经不在字节码上了。

5.2 字符串与正则的列式化

pandas 的 .str 访问器底层走的是向量化字符串内核（部分场景仍为 Python 循环，需实测）。对于复杂正则，可考虑：

• 用 pyarrow.compute 的字符串函数（如 match_substring_regex）；
• 预编译正则并用 Series.map 配合缓存；
• 对超长文本，先做分块再批量处理。

5.3 何时向量化“真的做不到”

有些逻辑天然带状态：滚动窗口内的自定义状态机、依赖上一行的分支、调用外部 API。这类问题需要换思路，而不是硬套向量化。常见替代：

场景	推荐方案	备注
状态机/滚动依赖	Numba njit 循环	编译后接近 C 速度
外部 API 调用	异步 IO + 批量	瓶颈在网络，不在 CPU
复杂业务规则	规则引擎/查表	把逻辑数据化
混合 dtype 逐行	Arrow Table + 列式内核	避免对象数组

六、第二层优化：apply 的合理边界与替代方案

6.1 apply(axis=1) 为什么慢

apply(axis=1) 会为每一行构造一个 Series，再调用用户函数。它比 iterrows 略快（少一次索引重建），但仍在 Python 层逐行。pandas 文档明确指出：apply 在行方向上是“逐行 Python 循环”，性能与向量化不在一个量级。

6.2 apply 的“正确用法”

• 列方向（axis=0）配合 NumPy 归约，通常可接受；
• 分组后 apply：groupby.apply 对每组做向量化，组数远小于行数时可行；
• 返回标量而非 Series，减少对象构造；
• 配合 raw=True 传 NumPy 数组而非 Series，可显著降开销。

# raw=True 时，x 是 ndarray，不是 Series
df.apply(lambda x: x[0] * 2 + x[1], axis=1, raw=True)

笔者认为，raw=True 是 apply 场景里性价比最高的一个开关：它把每行的对象构造成本降为数组切片，实测常能带来 2–4 倍提升（整合数据，来源见文末基准类参考）。

6.3 map / replace / 查表：把逻辑变成数据

很多“逐行 if-else”其实是离散映射。把分支条件与结果整理成字典或小表，用 Series.map 或 merge 完成，复杂度从 O(n) Python 调用降为哈希查找。这是工程上最容易被忽视、收益却最稳定的一招。

七、第三层优化：多进程、共享内存与分块

7.1 为什么多进程能绕开 GIL

每个进程有独立的解释器与 GIL，因此 CPU 密集任务可以真正并行。代价是：进程启动、数据序列化（pickle）、结果回传。对 DataFrame 而言，序列化成本可能吃掉全部收益，尤其是大对象数组。

7.2 三种数据传递策略对比

策略	机制	优点	风险
直接传 DataFrame	pickle 序列化	写法简单	大对象极慢、内存翻倍
分块传参	每进程只拿一片	序列化量可控	需设计分块边界
共享内存	multiprocessing.shared_memory / Arrow Plasma	零拷贝读取	生命周期管理复杂

7.3 分块 + 进程池的可操作模板

from concurrent.futures import ProcessPoolExecutor
import numpy as np

def process_chunk(arr2d):
    # arr2d: (k, m) ndarray，避免传 DataFrame
    a, b = arr2d[:, 0], arr2d[:, 1]
    return np.where(b % 7 == 0, a * 2, a - b)

def parallel(df, workers=8):
    arr = df[["a", "b"]].to_numpy()
    chunks = np.array_split(arr, workers)
    with ProcessPoolExecutor(workers) as ex:
        parts = list(ex.map(process_chunk, chunks))
    return np.concatenate(parts)

本文评述：多进程的正确姿势是“传数组、不传 DataFrame、传小不传大”。把 DataFrame 转成 ndarray 再分块，通常能把序列化开销降到可忽略；反之，直接传 DataFrame 给进程池，是常见的“越优化越慢”来源。

7.4 进程数怎么定

经验公式：workers ≈ min(物理核数, 内存上限 / 单进程峰值内存)。内存往往是真正的约束。若单进程峰值 2GB、机器 16GB，则 workers 不应超过 6，否则触发 swap，性能断崖式下跌。

八、第四层优化：Numba / Cython 编译路径

8.1 Numba njit：把逐行循环编译成机器码

当逻辑确实需要循环（状态机、滚动依赖），Numba 的 @njit 能把 Python 循环编译为 LLVM 机器码，并支持 parallel=True + prange 做真正的多核并行（Numba 内部释放 GIL）。

from numba import njit, prange
import numpy as np

@njit(parallel=True, cache=True)
def row_kernel(a, b, c_len):
    out = np.empty_like(a)
    for i in prange(a.shape[0]):
        if b[i] % 7 == 0:
            out[i] = a[i] * 2 + c_len[i]
        else:
            out[i] = a[i] - b[i]
    return out

注意：Numba 对字符串支持有限，通常需要先把字符串列编码为数值（如类别编码或长度）。笔者认为，Numba 的最大价值不是“比 NumPy 快”，而是“让必须逐行的逻辑也能快”。它填补了向量化与纯 Python 之间的空白。

8.2 Cython：更彻底但更重

Cython 通过类型标注把 Python 代码编译为 C 扩展，适合长期维护的核心内核。代价是构建链复杂、调试成本高。对一次性脚本，Numba 的投入产出比通常更好；对库级组件，Cython 更稳。

8.3 编译路径的适用判据

• 逻辑含状态、无法向量化 → 优先 Numba；
• 需要长期维护、被多方调用 → 考虑 Cython 或 C++ 扩展；
• 只是简单条件分支 → 先试 np.select，别急着上编译器；
• 字符串密集 → 先编码为数值，再进编译内核。

九、第五层优化：Arrow 内存布局与 Polars 并行模型

9.1 Arrow：列式内存 + 零拷贝

Apache Arrow 定义了跨语言的列式内存格式，字符串以 offset + data 的紧凑布局存储，避免了 Python 对象数组的指针追逐。pandas 2.x 起支持 Arrow-backed dtype（dtype_backend="pyarrow"），字符串列的内存与访问效率明显改善。

df = pd.read_csv("data.csv", dtype_backend="pyarrow")
# 或转换已有 DataFrame
df = df.convert_dtypes(dtype_backend="pyarrow")

9.2 Polars：查询引擎 + 多线程内核

Polars 用 Rust 实现，基于 Arrow 内存，查询计划可自动并行化。它的表达式 API 强制列式思维，天然规避逐行陷阱。对“必须逐行”的场景，Polars 提供 map_elements（旧称 apply），但官方同样建议优先用表达式。

维度	pandas	Polars
内存布局	BlockManager / Arrow 可选	Arrow 原生
并行模型	单线程为主，需手动多进程	查询级自动多线程
惰性执行	有限	LazyFrame 完整支持
生态成熟度	极高	快速成长

本文评述：Arrow + Polars 代表的是“从根上换掉执行模型”，而不是在 pandas 上打补丁。对于新建的数据管道，直接选列式引擎往往比后期优化更省力；对于存量 pandas 代码，先用 Arrow-backed dtype 过渡是低风险路径。

十、工程落地：5 倍加速的操作路径与检查清单

10.1 五步决策树

1. 定位热点：用 cProfile / py-spy 确认时间花在 Python 层还是 C 层；
2. 尝试向量化：np.where / np.select / .str / merge 查表；
3. 若必须逐行：先 raw=True 的 apply，再评估 Numba；
4. 需要多核：优先多进程 + ndarray 分块，而非多线程；
5. 长期方案：迁移到 Arrow/Polars 或把内核编译化。

10.2 避坑清单

• ❌ 对 CPU 密集的纯 Python 循环用 ThreadPoolExecutor；
• ❌ 把大 DataFrame 直接 pickle 给进程池；
• ❌ 在 apply 里做字符串拼接与正则，却不做编码；
• ❌ 用 iterrows 做数值计算；
• ❌ 只看 wall time，不看 CPU time 与内存峰值；
• ✅ 先测量、再优化、后验证，保留对照组。

10.3 一个可复用的“加速倍数”估算表

优化手段	典型加速区间	适用前提
iterrows → 向量化	20–100×	逻辑可列式表达
apply → raw=True	2–4×	函数只读数值列
单线程 → 多进程分块	3–8×	CPU 密集、内存充足
纯 Python → Numba	10–50×	数值循环、类型稳定
pandas → Polars	2–10×	可重写为表达式 API

注：上表为整合数据，综合 pandas 官方性能文档、Polars 官方基准（polars-benchmark 仓库）与社区公开基准整理，区间随数据规模、dtype、硬件差异较大，仅供量级参考。

十一、前沿预判：自由线程 Python 与列式引擎的下一步

11.1 自由线程会改变结论吗

PEP 703 的 free-threaded 构建在 3.13 进入实验阶段，3.14 继续推进。它让多线程真正并行成为可能，但短期内有两个现实约束：一是单线程性能存在一定回退（官方文档提示 free-threaded 构建在部分负载上更慢）；二是大量 C 扩展尚未适配。本文评述：即使 GIL 消失，“逐行构造对象”的成本仍在，行处理的根本解法依然是消除行级语义。

11.2 列式引擎与查询编译

Polars、DuckDB、DataFusion 等引擎正在把 SQL/表达式编译为向量化执行计划，部分场景引入 JIT。对 Python 用户而言，趋势是“把计算下沉到引擎，Python 只做编排”。这与本文主线一致：让 Python 远离热循环。

11.3 对工程团队的建议

• 建立“性能预算”：明确单批处理的 wall time 上限；
• 把基准脚本纳入 CI，防止性能回退；
• 在代码评审中禁止无说明的 iterrows/apply(axis=1)；
• 新项目优先评估 Arrow/Polars，存量项目渐进迁移。

十二、结论与延伸阅读

回到标题：DataFrame 行处理 5 倍加速，并不是靠“开更多线程”实现的。恰恰相反，GIL 版多线程在纯 Python 行处理上是典型的负优化。真正的加速来自三层协同：语义层消除逐行、内存层改用列式、执行层引入编译或并行。任何单点优化，若忽略另外两层，收益都会被稀释。

可操作的路径已经清晰：先 profile，再向量化，必要时 raw=True，再考虑多进程分块，最后用 Numba 或列式引擎兜底。全程保留对照组，用数据说话。