np.sum(arr)比arr.sum()运行慢的深层代码原因探究

先看实测数据：

import numpy as np
np.random.seed(7)
A = np.random.random(1000)
%timeit np.sum(A)
# 2.94 µs ± 13.8 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
%timeit A.sum()
# 1.8 µs ± 40.8 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

从代码执行逻辑来看，np.sum(arr) 比 arr.sum() 多了以下额外步骤，导致短数组场景下性能差异显著：

• 通用类型检查与分发开销
  np.sum 是NumPy的通用顶层函数，需要兼容所有可迭代输入（比如列表、其他数组类对象）。执行时它会先检查输入的类型，判断是否为ndarray，再分发到对应的求和实现；而 arr.sum() 是ndarray实例的专属方法，直接调用针对ndarray优化的底层C实现，跳过了这一层类型判断和分发逻辑。

• 通用参数解析的额外步骤
  np.sum 支持更广泛的参数（如axis、dtype、out等），即使不传这些参数，函数内部也会完成默认参数的解析、验证和适配工作；而 arr.sum() 作为实例方法，参数逻辑更精简，只针对ndarray的特性做处理，不需要兼容非ndarray场景的参数逻辑。

• 命名空间查找的微小开销
  调用 np.sum 时，Python需要先遍历np模块的命名空间找到sum函数；而 arr.sum() 直接在实例对象的属性中查找方法，查找路径更短。对于短数组求和，这种查找和分发的开销占总耗时的比例更高，所以差异明显；长数组求和时，计算本身的耗时占主导，这部分开销的影响就被稀释了。

内容的提问来源于stack exchange，提问作者Simd