fread($file, 8192)
より優れた、または安全なものはありfread($file, 10000)
ますか? ほとんどの例で 2 のべき乗が使用されているのはなぜですか?
3 に答える
FileInputStream を使用する場合、理想的なバッファ サイズをどのように決定しますか? .
ほとんどのファイル システムは 4096 または 8192 のブロック サイズを使用するように構成されています。一度に 4100 バイトを読み取るようにバッファを構成した場合、各読み取りにはファイル システムによる 2 つのブロック読み取りが必要になります)。ブロックがすでにキャッシュにある場合は、RAM の代償を払うことになります -> L3/L2 キャッシュのレイテンシー。運が悪く、ブロックがまだキャッシュにない場合は、ディスクから RAM へのレイテンシも犠牲になります。
これが、ほとんどのバッファーのサイズが 2 の累乗であり、通常はディスク ブロック サイズよりも大きい (または等しい) ことを示している理由です。これは、ストリーム読み取りの 1 つが複数のディスク ブロック読み取りになる可能性があることを意味しますが、それらの読み取りは常に完全なブロックを使用し、無駄な読み取りはありません。
質問は Java 関連ですが、答えは違います。さらに、それはほとんど言語に依存しません。その答えは、バッファサイズに関して私が知っているすべての要因をカバーしています。
オペレーティング システムは、ページ単位でメモリを割り当てます (通常は 4k - ただし、8k の場合もあります)。
この場合、8192 バイトの倍数のバッファー サイズを使用すると、より効率的なメモリ割り当てが可能になります (4096 バイトの倍数にも対応しているため)。
13k のメモリを要求すると、とにかく 16k が使用されるため、最初から 16k を要求しないでください。
CPU 命令セットは、32、64、または 128 ビットなど、特定の境界に整列されたデータを処理するように最適化されています。3 ビット、または 5 ビット、または奇妙に整列されたデータを扱うと、処理のオーバーヘッドが追加されます。
これは、OS 独自のメモリ管理に加えて Zend メモリ マネージャーを使用する PHP に固有のものではなく、おそらく前もってより大きなメモリ ブロックを割り当て、メモリ管理の懸念をユーザーから取り除きます。
次のいずれかの理由:
- 任意の数を選ぶとき、プログラマーは 2 のべき乗を選ぶのが好きです。
- ある種の時期尚早な最適化では、プログラマーは、ブロックサイズの倍数で読み取ると、ある種の速度が向上すると考えています。