私は非常に大きなファイル150GBを持っています。私は読み取り専用mmapを使用し、ファイルにバイナリ検索を実行します。非常に大きなファイルでmmapを最適化する
現在、バイナリ検索はかなり遅いです。
私はいくつかの値をチェック（ディスクシーク）すると、この値の "周り"の値はすべて、同じディスクブロックに属しているため、既にメモリに入っています。ファイルのどこかでジャンプするのではなく、 "近く"の値をチェックしてからジャンプすることができます。
この最適化を行う価値はありますか？
また、ディスクブロックがどこで終了するかを見積もることもできます。
B-treeデータ構造につながる推論のラインを見つけました。 の最適化は、の価値がありますが、できるだけ多くのデータを取得するには、ディスク上のデータを実質的に再編成し、バイナリ検索よりも複雑なアルゴリズムを使用する必要があります。おそらく、最初から実装するのではなく、既存のオープンソースのBツリーライブラリを調べるべきです。
mmapを使用しているため、アクセスの最小単位はディスクブロックサイズではなく、メモリ「ページ」サイズで、sysconf(_SC_PAGESIZE)で照会できます。いくつかのOSは、ファイルバックアップされた領域へのランダムアクセスで、より大きなメモリチャンクを読み込んで読み込みますが、どのくらいの可搬性があるのかわかりません。また、madvise(MADV_RANDOM)からいくつかの利点を得るかもしれません。
この推論の原因となるもう1つの方向は、キャッシュを知らないデータ構造です。これらはページサイズを知る必要はなく、複数のレベルのCPUキャッシュを利用することもできます。詳細はhttps://blogs.msdn.microsoft.com/devdev/2007/06/12/cache-oblivious-data-structures/をご覧ください。 – btilly
'madvise（MADV_RANDOM）'は60％スピードアップします。ニース、でもまだ遅い。 – Nick