Boost r樹在內存與映射文件中的性能差異

Question

我需要創建3D R *-樹，也許用於長時間存儲，但是性能也會成為問題。 為了創建樹，我決定使用Boost的spacialindex並基本找到了兩種可能的方法。

我要么直接使用對象在此處創建它，要么： 在vector中存儲的多邊形索引 ，但是這不允許我在不再次創建R * -tree的情況下存儲和加載它。

或者，我可以按如下說明使用映射文件： 使用Boost.Interprocess在映射文件中存儲索引 ，但是，在這種情況下，我不確定查詢的性能是否足夠好。

我的r樹將包含數千個條目，但最有可能少於100,000個。 現在我的問題是，與使用標准對象相比，使用映射文件是否存在任何強大的性能問題？ 另外，如果創建一個大約100,000個值的R *樹不需要花費大量時間（我可以將所有邊界框和相應的鍵/數據存儲在文件中），那么跳過該鍵可能是一個更好的選擇。映射文件並在每次運行程序時都創建樹？

希望有人可以在這里為我提供幫助，因為該文檔實際上並沒有提供太多信息（盡管仍然比libspacialindex的文檔更好）。

Answer 1

映射文件的行為基本上類似於常規內存（實際上，在Linux中，使用new或malloc內存分配將使用mmap [具有“無文件”后備存儲]作為基礎分配方法）。 但是，如果您“在整個地方”進行了許多小寫操作，並且正在通過REAL FILE進行映射，則OS將在寫文件之前限制緩沖寫操作的數量。

當主題出現前，我做了一些實驗，並且通過調整操作系統如何處理這些“掛起的寫操作”的設置，即使使用隨機讀/寫模式進行文件支持的內存映射，我也可以獲得合理的性能[我期望發生的事情在建造樹時]。

我認為這是“具有隨機寫入的mmap性能”問題，與以下問題密切相關： 具有隨機訪問C ++和Python的不良Linux內存映射文件性能 （此答案適用於Linux-其他操作系統（尤其是Windows）的行為可能完全不同關於如何處理寫入映射文件的問題）

當然，在每次運行程序時在內存映射文件或重建文件之間很難說“哪個更好” –這實際上取決於您的應用程序執行的操作，是每秒運行100次還是每天運行一次，重建需要多長時間[我絕對不知道！]，以及許多其他這樣的事情。 有兩種選擇：構建最簡單的版本，並查看其是否“足夠快”，或者構建兩個版本，並測量存在多少差異，然后確定要沿哪條路走。

我傾向於建立簡單的（ish）模型，如果性能不夠好，請找出緩慢的原因，然后加以解決-這樣可以節省大量時間，使事情花費了總執行時間的0.01％運行5個時鍾周期更快，最后在其他地方產生了沉思，這使其運行速度比您預期的慢500倍...

Answer 2

批量加載索引比反復插入快得多 ，並產生一種更有效的樹。 因此，如果您可以將所有數據保存在主內存中，建議使用STR批量加載來重建樹。 以我的經驗，這已經足夠快了（批量加載時間與I / O時間相形見））。

STR的成本大約是分類的成本。 理論上講， O(n log n)具有非常低的常數（效率較低的實現可能是O(n log n log n)但仍然相當便宜）。