含大量NaN的NumPy数组高效元素运算方法及掩码数组性能疑问

嘿，我来帮你把这两个问题掰扯清楚～

首先说为啥掩码数组（masked_arr_nans）运算慢这么多：

• NumPy的掩码数组（np.ma模块）本质上是维护了两个并行数组：一个存实际数据，一个存掩码标记。每次做运算的时候，它不仅要处理数据的计算，还要同步更新掩码的状态——比如判断运算后哪些位置应该保持掩码、哪些要解除，这额外的逻辑判断和双数组同步工作，会带来大量的开销。
• 而原生的NumPy数组（不管有没有NaN）的向量化运算，是直接在底层C代码里实现的高度优化操作，几乎没有额外的逻辑判断，所有元素的运算都是批量执行的，速度自然快得多。尤其是这种简单的元素级算术运算，掩码数组的额外开销会被放大得特别明显。

然后是你最关心的：处理这类含大量NaN的数组，最快的方式是什么？
其实你自己的测试结果已经给出了答案——直接对arr_nans做原生的向量化运算就好！

• 你看测试里test和test_nans的时间几乎没差，这是因为NumPy对NaN的原生处理是硬件级优化的：NaN参与算术运算的结果还是NaN，这个操作在底层是单周期的机器指令，和正常数值运算的速度几乎一样，完全不需要额外的“跳过”逻辑。
• 如果你尝试先提取非NaN元素再运算（比如arr_nans[~np.isnan(arr_nans)] *5/2.123），反而可能因为切片提取+重新赋值的额外开销，比直接整个数组运算更慢，完全没必要多此一举。

总结一下：

• 简单元素级运算：直接用原生NumPy数组运算，速度最快，结果也符合预期（NaN位置运算后还是NaN）。
• 掩码数组适合的场景是那些需要严格屏蔽NaN，不希望NaN参与任何中间计算逻辑的复杂操作（比如统计均值、求和时自动忽略NaN），但对于这种简单的算术运算，它的开销完全得不偿失。

备注：内容来源于stack exchange，提问作者IzaeDA