プログラマーがプロセスを考えた：Windows APIの

Question

でのReadFileを使用するときに読み込むバイトの最大数を決定する私は、Windows APIののReadFile関数を呼び出す必要があります：私は興味

BOOL WINAPI ReadFile(
    _In_  HANDLE  hFile, 
    _Out_  LPVOID  lpBuffer, 
    _In_  DWORD  nNumberOfBytesToRead, 
    _Out_opt_ LPDWORD  lpNumberOfBytesRead, 
    _Inout_opt_ LPOVERLAPPED lpOverlapped 
); 

引数を3一つである：バイトの最大数が読み取られる

[IN]

nNumberOfBytesToRead。

私はそこに置くのはあまり興味がありませんが、熟練したプログラマーは、そこに置く数を決定することが好ましく、番号が付けられたステップであることが好ましいです。

私はアセンブラで自分のプログラムを書いているので、私はその考え方から思考過程にもっと興味があることを覚えておいてください。

---

• https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467%28v=vs.85%29.aspx

Answer 1

これは、Windowsとハードウェアの両方への洞察力の多くを必要とします。しかし、一般的には、次のような方向があります。

• 書き込みはバッファリングされているのか、バッファされていませんか？バッファリングされていない場合は、サイズを選択することさえできないかもしれませんが、バッファのサイズとアライメントの両方について厳密な規則に従う必要があります。
• 一般に、オペレーティングシステムは、ユーザー空間で行うよりもストレージデバイス自体とそのさまざまなユーザーについて多くのことを知っているため、できるだけ多くの作業を処理させる必要があります。可能であれば、すべてを一度に取得したいかもしれません（下記の点を参照してください）。
• これで十分ではないことが判明した場合、OSが何らかの理由でカレントバッファを使用できるケースを考慮して、様々なサイズで遊んで、さまざまな要求に対していつも利用しません。
• それ以外の場合は、ディスクセクタサイズとページサイズの倍数の間のどこかにあるサイズで再生する可能性があります。これらはすでにどこかにキャッシュされている可能性が高いため、実際のハードウェア要求に直接マッピングする可能性があります。
• パフォーマンス以外に、いつでもプロセスのメモリにどれくらい保存できるかという問題があります。
• OSがまだ何らかの形でそれを世話していない場合、他のプロセスがそこに入り、いくつかのデータを—の間に取得するのを妨げるかもしれない大きな要求を送るという問題もあります。
• また、あまりにも大きいチャンクを要求すると、他のプロセスが自分の謙虚なものを提供するまでOSが要求を延期する可能性があります。反対側では、アドレスと交差する場合は、キャッシュから他のアドレスを提供するために、実際にアドレスを提供することがあります。

一般的には、十分にうまくいくものが得られるまで遊んでみたいです。

Answer 2

これは、バッファオーバーフローからあなたを守るためだけのことですので、もちろんこの目的のために割り当てたバッファのサイズを入力する必要があります。それ以外の場合は、この正確な時刻に興味のあるバイト数だけを読んでください。現代のOSは常にpagecacheを使用し、その後のファイルへのアクセスはRAMにアクセスするほど速くなります。必要な場合は、あらかじめOSに強制的にファイルをキャッシュさせることもできます。
編集：私の経験はヤンMarcovicと他の人が推薦するものに対してです。ファイルのキャッシュと理想的なサイズへの読み込みは、OSが行うべきこととまったく同じです。あなたがそれを凌駕して、あなたが必要とするものだけを読むとは思わないでください。