我需要创建一个3D R * -tree，也许是为了长时间存储，但性能也是一个问题。 为了创建树，我决定使用Boost的spacialindex，基本上找到了两种可能的方法。
我可以使用对象直接创建它：Index of polygons stored in vector但是，这不允许我存储和加载它而不再创建R * -tree。
或者我可以使用映射文件，如下所述：Index stored in mapped file using Boost.Interprocess但是，我不确定在这种情况下查询的性能是否足够好。
我的r-tree将包含数千个条目，但很可能少于约100,000个。现在我的问题是，与使用标准对象相比，使用映射文件是否存在任何强大的性能问题？此外，如果创建大约100,000个值的R * -tree不需要花费大量时间（我可以将所有边界框和相应的键/数据存储在文件中），那么跳过它可能是更好的选择。映射文件，每次运行程序时都创建树？
希望有人可以在这里帮助我，因为文档并没有真正提供太多信息（尽管它仍然比libspacialindex的文档更好）。
答案 0 :(得分：4)
映射文件的行为大致类似于常规内存（事实上，在Linux中，new或malloc的内存分配将使用mmap [带有“无文件”后备存储]作为基础分配方法）。但是，如果您“在所有地方”进行了许多小写操作，并且您正在映射到REAL FILE，那么操作系统将在写入文件之前限制缓冲写入的数量。
我刚刚在主题出现时做了一些实验，通过调整操作系统如何处理这些“挂起写入”的设置，即使对于具有随机读/写模式的文件内存映射，我也获得了相当的性能[某事我希望你在构建你的树时会发生这种情况。
这是“随机写入mmap的性能”问题，我认为这是高度相关的： Bad Linux Memory Mapped File Performance with Random Access C++ & Python （这个答案适用于Linux - 其他操作系统，特别是Windows，在处理映射文件的写入方面可能表现完全不同）
当然，很难说“哪个更好”，内存映射文件或每次运行程序时重建 - 这实际上取决于你的应用程序做什么，无论你每秒运行100次，还是一次一天，重建需要多长时间[我完全不知道！]，还有很多其他类似的东西。有两种选择：构建最简单的版本，看看它是否“足够快”，或者构建两个版本，并测量它们有多大差异，然后决定哪条路径下降。
我倾向于构建简单（ish）模型，如果性能不够好，找出缓慢来自哪里，然后修复它 - 它节省了大量时间制作需要0.01％的东西总执行时间更快地运行5个时钟周期，最后在其他地方运行一个大的思考，使其运行速度比预期的慢500倍......
答案 1 :(得分：0)
批量加载索引很多比重复插入更快，并产生更高效的树。因此，如果您可以将所有数据保存在主内存中，我建议使用STR批量加载重建树。根据我的经验，这足够快（大量加载时间与I / O时间相比相形见绌）。
STR的成本大致是排序成本。 O(n log n)理论上，具有非常低的常数（效率较低的实现可能是O(n log n log n)但是仍然相当便宜）。