为何多次调用numpy.linalg.norm处理小尺寸数据时速度缓慢？

这是个非常典型的numpy性能误区案例，咱们结合你的实验数据来拆解背后的核心原因：

1. 每次调用的固定开销占比过高 #

numpy的np.linalg.norm本质是为numpy数组设计的高性能函数，但你传入的是Python原生的range对象——这意味着每次调用np.linalg.norm时，它都要先隐式执行np.asarray(l)，把range转换成numpy数组。

对于大尺寸数据（比如10⁴个元素），这个转换开销和后续的C级别计算开销比起来可以忽略；但对于小尺寸数据（10²个元素），转换开销的占比会变得极高，甚至超过计算本身的耗时。而你的自定义norm函数直接遍历range，完全没有这个转换步骤，自然省掉了这部分开销。

2. numpy的通用逻辑带来的额外开销 #

为了适配各种场景（比如不同维度的数组、不同的范数类型、不同的数据类型），np.linalg.norm内部包含了大量的分支判断、参数校验逻辑。这些逻辑在处理大数组时，分摊到每个元素的开销微乎其微；但处理小数组时，每一次调用都要执行这些通用逻辑，累积起来的耗时就非常可观了。

反观你的自定义norm，是完全针对一维序列的极简实现：只做平方累加和开根号，没有任何多余的分支判断，针对性极强，在小数据场景下反而更高效。

3. Python与C的跨层调用累积开销 #

np.linalg.norm的核心计算是在C层面完成的，但每次从Python代码调用这个函数，都要经过Python解释器的调度、参数传递等跨层操作。当调用次数达到10⁷次这种量级时，无数次的跨层调用开销会被急剧放大。

而你的自定义函数是纯Python代码实现的循环，虽然单轮循环的速度不如C，但它不需要每次都做跨层调度，调用的固定成本极低，在超高频次调用的场景下，反而能跑出更好的总耗时。

验证思路：提前转换数据类型 #

如果把输入提前转换成numpy数组，再重复调用np.linalg.norm，你会发现小数据场景的性能会大幅提升——因为我们把单次的转换开销变成了一次性操作，剩下的就是numpy擅长的C级计算了。比如修改你的测试代码：

arr = np.array(range(10**2))
foo(10**2, 10**7, lambda x: np.linalg.norm(arr))

这时候numpy的性能应该会超过自定义函数，也能验证我们上面的分析。

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