4000x4000x3的Numpy数组：为何直接减列表比逐通道循环慢20倍？

给定一个形状为4000x4000x3的Numpy数组（对应3通道图像），需要为每个通道减去对应数值。测试发现以下两种实现方式中，后者的运行速度比前者快20倍，下面解释背后的原因：

两种实现方式 #

实现1 #

values = [0.43, 0.44, 0.45]
image -= values

实现2 #

values = [0.43, 0.44, 0.45]
for i in range(3):
    image[...,i] -= values[i]

验证脚本与结果 #

import time
import numpy as np

image = np.random.rand(4000, 4000, 3).astype("float32")
values = [0.43, 0.44, 0.45]

st = time.time()
for i in range(3):
    image[..., i] -= values[i]
et = time.time()
print("Implementation 2", et - st)

st = time.time()
image -= values
et = time.time()
print("Implementation 1", et - st)

输出结果：

Implementation 2 0.030953645706176758 
Implementation 1 0.8593623638153076

性能差异的核心原因 #

1. 临时数组的内存开销
   实现1中，image -= values执行时，Numpy会先把列表values转为numpy数组，再通过广播机制生成一个和image完全一样大的临时数组（4000×4000×3）。这个临时数组仅float32类型就占192MB内存，创建、填充和销毁它会消耗大量时间。而实现2直接操作原数组的通道视图，完全不需要额外创建大尺寸临时数组，内存开销可以忽略。

2. 数据类型转换的额外消耗
   values里的元素是Python默认的float64类型，而image是float32类型。实现1的广播操作会把image的所有元素临时提升为float64计算，再转成float32存回，这两次批量类型转换会大幅增加运算时间。实现2则是针对单个通道，Numpy会自动把单个float64值转成float32后直接运算，避免了批量类型转换的开销。

3. 内存访问的缓存效率差异
   实现2循环处理单个通道时，虽然通道内的元素在内存中是间隔分布的，但CPU的缓存预取机制会批量加载相邻内存块，加上循环仅3次，整体缓存利用率很高。而实现1需要同时读取原数组和广播生成的临时数组，两个大数组的内存访问会引发缓存冲突，降低缓存命中率，拖慢运算速度。

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