我有一个类似于这个问题的情况：
在多处理进程之间共享大型只读 Numpy 数组
除了一个显着的差异，我绝对希望整个阵列都位于 RAM 中。为了清楚起见，重申一下：
我想在多个进程之间共享一个相当大的 numpy 数组，只读，并将整个数组保存在 RAM 中以获得绝对的最佳性能。仅 Linux 的解决方案很好。我也希望这在生产环境中工作，所以宁愿避免依赖面向研究的软件包，或者做任何黑客的事情。
对于这种情况，在我看来，numpy-sharedmem风格方法是矫枉过正的。仍然突出的方法有：
-
在这里的另一个线程中建议将数组保留为全局变量并简单地
fork().这似乎是尽可能快的。与单进程方案相比，多个进程最终是否会以任何方式竞争共享内存页，或者以某种方式干扰彼此的缓存，从而引入一些开销？尽管由于这样的评论，我对这种方法持怀疑态度。尝试在我的多处理环境中使用
fork()也可能不方便(此时我很可能使用 Twisted)。 -
虽然numpy的内置内存映射是在另一个线程中提出的，但它显然是针对比主内存更大的数组的。我不相信我已经在stackoverflow上看到了以下可能性：为什么不直接将npy文件放入虚拟硬盘并将其mmap(
mmap_mode='r')以获得简单稳定的只读内存中共享numpy数组？此处的性能注意事项是什么？它与
fork()方法或真正的共享内存方法(例如numpy-sharedmem)有很大不同吗？在 numpy 中，mmap 层会产生多少开销？当 npy 文件放置在虚拟硬盘上时，连续性很重要吗？缓存局部性是否受到影响？进程之间会有任何争用吗？
我倾向于仅针对稳定性因素的选项 2，但想了解可能的性能差异，并了解为什么 mmap+ramdisk 对于许多与我的相似或不那么相似的应用程序来说可能是一个快速简便的解决方案。
使用虚拟硬盘将涉及访问文件系统、在虚拟硬盘和页面缓存之间复制数据以复制数据所涉及的所有开销。
如果您使用 ramfs，则不会有访问将被锁定在 RAM 中的数据的开销。但是，这意味着其他数据将无法保存在RAM中，从而可能降低整体性能。
使用 tmpfs 具有与匿名内存类似的性能。