我们有一个场景，我们动态增长一个用于 boost 的 r-tree 几何索引的内存映射文件。我们还利用了 boost 的进程间内存映射文件 api。
机制已经在取消映射文件、增长和重新映射方面进行了整理 - 这一切都有效。
到目前为止，我们已经尝试使用坐标固有尺寸的 10 倍来高估尺寸，这种方法有效，但在使用 du 进行检查时被严重高估了。
在给定对象数量的情况下，是否有某种方法可以预测（最坏情况或精确）我们应该要求映射文件增长的大小？低估，例如因子 5，最终会导致堆栈粉碎......
谢谢
【问题讨论】：
标签： c++ memory-mapped-files boost-interprocess boost-geometry r-tree
从纯粹意义上讲，这个问题在很大程度上与 boost-interprocess 无关。
您想了解分配模式（不仅是净分配量，还包括由于碎片导致的有效“池”使用情况。
你可以做的是分配器使用的统计数据（好问题：有没有某种收集统计数据的分配器适配器？）并计算出来。
当然，您将处于近似范围内，但如果有足够的模拟运行，您应该有可用的信息。
作为最后的手段，Boost Geometry 的源头/开发者会被问到。
关于 Boost Interprocess，我们不知道您使用的是什么。我将假设managed_mapped_file/managed_heap_memory/managed_external_buffer。请注意，当将这些与默认内存分配策略 (rbtree_best_fit) 一起使用时，可能会产生相当大的碎片或只是分配开销（对于基于节点的容器，可能包括 rtree）。
相关示例：
这会立即为您提供一些使用想法：
shm.get_free_memory() 获取段中剩余空间的原始数字最后，不要忘记分配一个稀疏文件可能非常便宜，即使是 10 GiB，只需使用共享内存管理器进行分配：只有实际使用的页面才会提交到磁盘，因此实际磁盘使用量将与实际所需大小非常匹配。
稀疏文件很神奇。
【讨论】：