17370845950

核心原因是apply默认逐组构造新DataFrame/Series对象，触发完整Python层循环和对象开销，而agg/transform在底层尽可能复用向量化操作或C优化路径。

核心原因是 apply 默认逐组构造新 DataFrame/Series 对象，触发完整 Python 层循环和对象开销，而 agg/transform 在底层尽可能复用向量化操作或 C 优化路径。

apply 默认走 Python 解释器循环，无法跳过对象构建

当你对 groupby 对象调用 apply(func) 且未指定 axis 或传入标量函数时，pandas 会为每一组单独提取子 DataFrame（或 Series），再把该子对象传给你的函数。这个过程包含：

• 每组都新建一个 pandas 对象（含索引、dtype 检查、内存拷贝等）
• 函数调用在 Python 解释器中执行，无法被 numba/Numpy 的 C 循环加速
• 返回值还要被收集、拼接、对齐，涉及额外的索引重建和类型推断

agg 和 transform 优先调用内置优化实现

像 .agg(['mean', 'sum']) 或 .transform('std') 这类操作，pandas 会直接映射到内部已编译的高效路径：

• 绕过 Python 层，直接调用 NumPy 的 ufunc 或 Cython 实现的分组聚合（如 libgroupby 模块）
• 不构造中间组对象，而是通过指针偏移 + 长度信息，在原始数组上做原地计算
• 支持输出广播（transform）或压缩（agg）的零拷贝优化，避免冗余内存分配

即使写自定义函数，apply 也难逃开销瓶颈

比如你写 df.groupby('key').apply(lambda x: x['val'].mean())，看似简单，但实际仍经

• 每组生成 x（DataFrame 子视图或副本，取决于是否可切片）
• 再从 x 中取列 'val' → 又一次对象访问和 Series 构造
• 调用 .mean() —— 虽然这个方法本身是优化的，但外层 apply 的调度成本已远超计算本身

换成 df.groupby('key')['val'].agg('mean')，就直接走分组+数值列均值的专用通道，跳过所有中间对象。

怎么缓解 apply 的性能问题

如果必须用 apply，可通过以下方式减少损耗：

• 用 groupby(...).apply(func, include_groups=False)（pandas ≥ 2.1）避免传入 group key 列
• 确保函数接收的是 Series（如先选列：df.groupby('key')['val'].apply(...)），比传整个 DataFrame 快数倍
• 用 numba.jit 加速纯数值计算逻辑，并配合 Series.to_numpy() 输入，彻底脱离 pandas 对象
• 能用 agg/transform + 字符串名 / 内置函数 / 元组组合的，绝不手写 apply