NumPy实现随机游走速度远慢于纯Python？是否是使用方式有误？

核心问题根源 #

• NumPy小数组的固定操作开销远高于Python原生标量计算
  逐次循环流程中，你每一步都要完成两个高开销操作：用np.array()把Python列表转换为2元素的numpy数组、对location和move两个ndarray执行加法运算。这些操作背后，NumPy需要完成类型校验、内存布局检查、广播规则校验、ndarray对象实例化等全流程固定逻辑，哪怕数组只有2个元素，这些流程的开销也不会缩减。
  对比原生版本的x、y两个Python内置整数，加法操作直接对应轻量的Python字节码执行，没有额外的对象创建、规则检查成本。2万次循环累积下来，NumPy版本的额外开销被持续放大，最终耗时达到原生版本的8倍。
• 没有发挥NumPy的核心优势
  NumPy的速度优势来自于把多层循环的计算逻辑下沉到C语言层批量执行，彻底消除Python解释器的循环开销。如果始终在Python层面逐次循环调用NumPy接口，每次都要在Python解释器和C扩展之间做上下文切换，这些切换开销会远大于实际的计算成本，完全体现不出NumPy的速度优势。

可参考的高性能NumPy实现 #

不要在循环里逐次创建数组、逐次执行移动操作，通过向量化一次性完成所有步的计算：

import numpy as np

def random_walk_fast(n):
    # 预定义所有可选移动方向
    directions = np.array([[0, 1], [0, -1], [1, 0], [-1, 0]])
    # 一次性随机生成n步的方向选择，无Python层循环
    step_indices = np.random.randint(0, 4, size=n)
    # 批量取出所有步的移动量，直接求和得到最终坐标
    final_location = directions[step_indices].sum(axis=0)
    return final_location

这个实现执行2万步随机游走的耗时，通常比最初的纯Python循环版本快1~2个数量级。

NumPy使用注意事项 #

• NumPy的速度优势有适用边界：只有当处理的数组规模足够大，能把固定的对象创建、上下文切换开销充分摊薄时，才能体现性能收益。如果操作的是个位数元素的极小数组，且在高频循环里反复创建ndarray，NumPy的开销会远高于原生Python代码。
• 尽量避免在高频Python循环里逐次调用NumPy接口，优先用向量化操作替代手动for循环。

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