为何Numba中typed list的元素访问速度远慢于NumPy数组？

造成二者访问速度差距的核心原因来自内存布局、编译器优化权限两个层面，你的测试场景也进一步放大了这种差距：

• 内存布局的本质差异
  NumPy数组是连续同构的内存块，所有元素直接存储在同一片连续地址空间中，访问pos[i][0]时仅需要做一次基地址+偏移量的计算即可直接读取内存，额外开销近乎为0。同时连续内存的特性也让CPU缓存命中率极高，进一步降低访存耗时。
  而Numba typed List本质是动态指针数组，存储的不是元素本身，而是指向各个元素的指针，你的测试中每个长度为3的浮点数组都是单独分配在堆内存的，访问pos[i][0]时需要先读取List中i位置的指针，再对指针做解引用才能拿到实际的元素值，多了一层指针跳转的开销，同时分散的内存布局也会导致CPU缓存命中率大幅下降。
• 编译器优化空间差异
  NumPy数组的维度、步长、元素类型在编译期就完全确定，LLVM（Numba底层依赖的编译器）可以做非常激进的优化：你的测试中dx、dy、dz计算后没有被使用，编译器直接判定这部分数组访问代码无副作用，直接将其整体优化删除，所以最终numpy版本的耗时和仅生成随机数的耗时几乎一致。
  而typed List属于可变动态结构，编译器无法在编译期确定其内存布局，也无法证明List的访问操作没有边界异常等副作用，因此不敢删除你写的元素访问代码，必须逐行执行，同时也无法做向量化、常量折叠、步长预计算等优化，还要额外执行运行时边界检查，进一步拉高了耗时。
• 测试场景的放大效应
  你的测试用例属于典型的访存密集、计算量极低的场景，访存开销的占比被拉到极高，因此两种数据结构的访存效率差异会被放大到几十倍的水平，如果是计算密集的场景，相对差距会有所缩小。

优化建议 #

如果你的场景不需要对容器做动态增删元素操作，优先使用NumPy数组即可获得最优性能；如果必须使用动态容器，可以考虑将固定长度的小元素拆分为独立的基础类型存储，减少指针解引用的开销，比如把(N,3)的坐标拆为x、y、z三个独立的typed.List[float]，访问速度会有明显提升。

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