为什么Python Pandas的apply函数执行很慢及如何优化？-Python教程-PHP中文网

apply慢是因其默认逐行调用python函数，产生大量对象开销；数值、字符串、时间列上均因无法向量化而显著降速，应优先使用列级向量化操作。

为什么python pandas的apply函数执行很慢及如何优化？

apply 慢不是因为你写得不够好，而是它天生不适合多数场景——Pandas 的 apply 默认走 Python 解释器逐行调用路径，每调用一次函数，就创建一次 Series 对象、压一次 Python 栈、做一次类型检查。哪怕你只算个 x['a'] + x['b']，开销也远大于直接用列运算。

为什么 `apply` 在数值/字符串/时间列上都容易变慢

数值列：每次传入的是 pandas.Series，不是 NumPy 数组，无法触发底层 C 运算；即使函数逻辑简单，Python 函数调用本身就有固定 overhead
字符串列：str 访问器方法（如 .str.contains()）是向量化的，但 apply(lambda x: x.startswith('A')) 会退化为纯 Python 循环
时间列：Series.apply 对 datetime64 类型有特殊行为，首次调用可能把整个 DatetimeIndex 当作参数传入，导致 AttributeError 或逻辑错乱

常见错误现象：

df['date'].apply(lambda x: x.year) 报 AttributeError: 'DatetimeIndex' object has no attribute 'year'
df.apply(lambda row: row['val'] > 0, axis=1) 比 df['val'] > 0 慢 50 倍以上（实测百万行数据）

能不用 `apply` 就别用：优先向量化替代方案

向量化不是“高级技巧”，是 Pandas 正常用法。只要操作可广播（broadcastable），就该用列级运算：

python-docx

python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集

下载

数学运算：直接用 +、np.log()、df['a'] ** 2，别写 apply 包裹的循环
条件赋值：用 np.where() 或 df.loc[mask, 'col'] = value，而不是 apply + if/else
字符串处理：用 df['text'].str.upper()、.str.extract(r'(\d+)')，不是 apply + re.match
时间处理：用 df['ts'].dt.hour、.dt.to_period('M')，不是 apply + .timestamp()

性能差异真实存在：

df['a'] * df['b'] + df['c']：约 3ms（100 万行）
df.apply(lambda r: r['a'] * r['b'] + r['c'], axis=1)：约 850ms（同数据）

实在绕不开 `apply`？试试这三种加速路径

swifter：自动判断是否启用 Dask/multiprocessing，适合中等复杂度、无状态函数
df['new'] = df.swifter.apply(lambda x: custom_logic(x), axis=1)
⚠️ 注意：启动线程池有开销，小数据集反而更慢；不支持带全局变量或 IO 的函数
numba.jit：仅适用于纯计算逻辑（无 Pandas/Numpy 高阶对象），且输入必须是 NumPy 数组
@numba.jit(nopython=True)
def fast_sum(arr): return np.sum(arr)
然后用 df.groupby('key')['val'].agg(fast_sum)，不能用于 apply，必须配合 agg 或手动切片数组
rapidfuzz.process.cdist：专治模糊匹配类 apply，把两组字符串一次性算完相似度矩阵
from rapidfuzz import process
sim_matrix = process.cdist(df['name'], choices, scorer=process.token_sort_ratio)
⚠️ 内存敏感：10 万 × 10 万对比较会占约 8GB 内存（float64）

`apply` 不是万能胶，也不是最后手段

真正难优化的从来不是“怎么让 apply 更快”，而是“为什么非得用 apply”。很多所谓“必须用 apply”的场景，其实只是没意识到 pd.cut、df.assign、groupby.agg 或 numpy.select 就能覆盖。一旦写出 apply，先花 30 秒问自己：这个操作能不能拆成几个向量步骤？有没有现成的 .str / .dt / .cat 方法？