ファイルを一度に読むのと比較して、行ごとに読み方を変えると（理論上）大きな違いはありますか？ファイルを1行ずつ読み込むときのパフォーマンス対ファイル全体を読み込むときの比較
ファイル全体を読み取ると、使用されるメモリの量に悪影響がありますが、動作は速くなりますか？
ファイルを読み取り、各行を処理する必要があります。一度に1行ずつ読み込んで処理するか、ファイル全体を読み込んですべて処理した後に出力するかはわかりません。
私はすでに行ごとに読み込むようにprgmを設定しています。私は、ファイル全体を読むためにそれを変更する努力が必要かどうかを知りたいと思います。
おかげで、
正直に言うが、私の学位の間、しばらくの間、効率性を学んだ後、私はあなたの質問についてはこちらを締結するようになった：それは、このファイルを読み取ることが起こっているか頻繁に依存します。それを一度読んだら、それだけで他の仕事のためのプロセスを解放するので、全部をやってください。 あなたの頭に留めておくべきもう1つのことは、後でファイルを編集して更新する必要がある場合です（更新された部分のみを読み込みます）。そうすれば、どこから読み込むかを再現するようにマーカーを設定する必要があります再度更新頻度？）。しかし、それが一度の仕事であれば、ファイル内の特定のリテラルのトークンを作成する必要がないかぎり、それを全体として読むことができます。 これが役立つことを願っています。
最新の* nix、またはWindowsオペレーティングシステムでは、この種のもの（バッファリング、プロセス間の共有、アップデートのマーキング）はすべてオペレーティングシステムによって行われます。 –
私は同意する....時には人々が効率をあまりにも深刻に取ると、実際にはそれが悪化する！つまり、バッファリングの実装/妨害、プロセス間の共有、更新のマーク付けなどです。 –
ファイル全体をメモリに読み込むのは一般的にはお勧めできません。ファイルが膨大になり、メモリが大量に消費され、最悪の場合メモリが不足するからです。したがって、パフォーマンスとメモリ使用のバランスをとるために、ファイルのブロックをバッファに読み込み、バッファを解析します。ブロックの処理が完了したら、EOFまで次のブロックを読み取ります。
ブロックサイズを適切に決めるには、達成したいことに基づいて行う必要があります。
ファイルシステムは、この "ブロック"をあなたのためにすべて行います！ OSのバッファリングの上に独自のバッファリングを実装することで、バッファ管理が遅れてしまうだけです。 –
@ジェームズアンダーソン - あなたは正しいです：私はちょうど "理論的に"言及OPとして排他的にしました。 – srikanta
ファイル全体を読むのが少し速くなりますが、あまり効果はありません。
しかし、ファイルサイズがプログラムのRAM容量を超えると、スワップ領域の使用がはるかに遅くなるので、ファイル全体がスケーラブルでないことに注意してください。ファイルサイズが使用可能な仮想メモリのサイズを超えると、プログラムがクラッシュします。
どれくらいのデータを読んでいるのか、プログラムの実行にどれくらいの時間がかかるか、つまりパフォーマンスに何か効果があるかどうかということです。
this answerの本の引用符を参照して、ソフトウェアの性能について考えてください。他の人のように
（私はあなたが理論に答えのためだけど、あなたが過ごすには有限の時間を持っていたときに、パフォーマンスを心配するときのこの態様は、も重要である。）
、より大きな読み込みを行うと、アプリケーションのパフォーマンスが向上すると思われますが、I/OはすでにOSレイヤーでバッファされているので、読み込み回数が多すぎるというオーバーヘッドを減らすことで獲得できます。入力ファイルの最大サイズを知っていない限り、ファイル全体を一度に読むことは危険です。最も合理的なアプローチは、ファイルを大きなブロックで読み取ることです。
さらに改善したい場合は、I/Oと処理を重複させることを検討する必要があります。 128MBのブロック単位で入力ファイルを読み込んだとします。あなたのメインスレッドでは、最初の128MBのブロックを読み込んだ後、処理のためにワーカースレッドに渡します。ワーカースレッドが動作する間、メインスレッドは第2の128MBブロックを読み込みます。その時点から、ワーカースレッドがブロックNを処理している間、メインスレッドはディスクからブロックN + 1を読み込んでいます。
私はそれがアプリケーションのニーズに依存すると思う（ほとんどのもののように、私は知っている）。ノードjsの1 MBファイルを読み取ることは、fs.readFile（）を使用して読み込みストリームまたはラインリーダーを使用するよりも、ファイルの読み取りが行われる場合に比べて3〜4倍高速です。ファイルが非常に大きく、入力をオンザフライで処理している場合、ストリームはいくつかの追加のパフォーマンスを提供する可能性があります。ノードプロセスが64ビットシステムで〜1.5 GBのメモリ制限を持つため、アプリケーションがすでに多くのメモリを消費している場合にも理想的です。 CPUの処理速度（HDDやテープ上のアーカイブ、TCPのようなネットワーク接続）に比べて、データのソースが遅い場合には、処理チャンクのパフォーマンスが向上する可能性があります。メモリにファイルを読み込んでメモリにストリーミングするまでは、データイベントを発行し、処理関数のコールバックに切り替えて関数のオーバーヘッドを推測して、プロセスを遅くしています。
理論上、ドライブは、他に何が起きているかに応じて、行単位のプログラムでより頻繁にシークして読み取る必要があります。実際には、これは問題にはならないかもしれません。なぜなら、バッファされたファイルI/Oはおそらくより大きなブロックで読むために使われているからです。あなたの走行距離は、ハードウェアとアルゴリズムの詳細によって異なります。最適化するときは、プログラムの複数の反復を記述し、タイマーコードを追加するか、プロファイラを使用して何が最も時間を費やしているかを調べる必要があります。 – holtavolt