我遇到过这个问题的一些通用版本，要求对共享内存/ tmpfs / mmap / block读取进行一般比较，但是我想问一下这个问题的特定于应用程序的版本来试图找出在延迟方面更有效的方法。
我有一个图像处理库的绑定，它只提供写入命名文件的选项，而不是提供任何直接到内存的字节数组选项。我使用此库作为服务器的一部分，该服务器读取多种不同格式和大小的源图像，应用大小/颜色转换，并将此图像的缩略图版本缓存在LRU缓存的内存中。然后，服务器通过http从LRU中提供这些缩略图。服务器将具有有限数量的图像工作者（例如2-4）。源图像的平均大小范围为100KB-20MB。输出图像大小的平均范围为20KB-1MB。
我之前使用的我之前的图像处理库能够将输出图像写入字节数组，现在我正在尝试切换到另一个库。所以我正在评估我解决这个输出限制的选择。
我一直在调查mmap和tmpfs作为选项，我有一些想法的组合，但根据我的访问模式，我希望听到有关开销的一些明智的回应或并发症。
我对/dev/shm的关注是关于可移植性的，因为我不想自己为我的应用配置/安装它，它可能是一个固定的大小（尽管很可能存在并且很大） ）。我还不清楚当/tmp中的普通块支持预分配文件是mmap＆d并且图像库写入它并且我从中读回来时会发生什么。事物的读数是否有任何好处？
将{file，memory} -backed图像缓冲区用于mmap是否有以下可能的方法？
/dev/shm，请为每个图像工作者预分配一个由内存支持的文件/dev/shm，请为每个图像工作者预分配正常的/tmp文件