2

おそらく長期保存のために、3D R* ツリーを作成する必要がありますが、パフォーマンスも問題になります。ツリーを作成するために、Boost の spacialindex を使用することにし、基本的に 2 つの可能な方法を見つけました。

ここにあるオブジェクトを使用して直接作成します: Index of polygons stored in vectorですが、R* ツリーを再度作成せずに格納してロードすることはできません。

または、ここで説明されているように、マップされたファイルを使用することもできます: Boost.Interprocess を使用してマップされたファイルに格納されたインデックス、ただし、この場合、クエリのパフォーマンスが十分に優れているかどうかはわかりません。

私の r ツリーには数千のエントリが含まれますが、おそらく約 100,000 未満です。ここで私の質問は、標準オブジェクトを使用する場合と比較して、マップされたファイルを使用することで大きなパフォーマンス上の問題はありますか? また、約 100,000 の値の R* ツリーの作成にそれほど時間がかからない場合 (すべてのバウンディング ボックスと対応するキー/データをファイルに保存できます)、マップされたファイルを作成し、プログラムを実行するたびにツリーを作成するだけですか?

ドキュメンテーションは実際には多くの情報を提供していないので、誰かが私をここで助けてくれることを願っています (それでも、libspacialindex のドキュメンテーションよりは優れています)。

4

2 に答える 2

4

マップされたファイルは、ほとんど通常のメモリのように動作します (実際、Linux では、基になる割り当て方法として [「ファイルなし」バッキング ストレージを使用するか、newまたは使用する] メモリ割り当て)。ただし、「いたるところに」多くの小さな書き込みを行い、REAL FILE にマッピングしている場合、OS はファイルに書き込む前にバッファリングされる書き込みの量を制限します。mallocmmap

少し前に話題になったときにいくつかの実験を行いました.OSがこれらの「保留中の書き込み」を処理する方法の設定を調整することにより、ランダムな読み取り/書き込みパターンを持つファイルバックメモリマッピングでも適度なパフォーマンスが得られました[何かが起こると期待していますツリーを構築しているとき]。

「ランダム書き込みを伴う mmap のパフォーマンス」の質問は、非常に関連していると思います: ランダム アクセス C++ および Python を使用した Linux メモリ マップ ファイルのパフォーマンスが悪い (この回答は Linux に適用されます - 他の OS、特に Windows では、まったく異なる動作をする可能性があります。マップされたファイルへの書き込みを処理する方法に関して)

もちろん、プログラムが実行されるたびにメモリ マップされたファイルと再構築の間で「どちらが優れているか」を言うのはかなり難しいです。実際には、アプリケーションが何を実行するか、1 秒間に 100 回実行するか、1 日に 1 回実行するかによって異なります。再構築にかかる時間 [ま​​ったくわかりません!] など、他にもたくさんあります。2 つの選択肢があります。最も単純なバージョンをビルドして、それが「十分に高速」かどうかを確認するか、両方のバージョンをビルドして、どの程度の違いがあるかを測定し、どちらの道をたどるかを決定します。

私は単純な（っぽい）モデルを構築する傾向があり、パフォーマンスが十分でない場合は、遅さの原因を突き止め、それを修正します。これにより、総実行時間の 0.01% かかるものを作成するのに多くの時間を費やすことができます。 5 クロック サイクル速く実行し、予想よりも 500 倍遅く実行する大きな思考が別の場所で発生します...

于 2015-01-30T08:55:49.050 に答える