編集する必要のある大きなファイル（ほとんどはフラットテキストファイルですが、CSV、固定幅、XMLなど）があることを予測できるプロジェクトを開始しようとしています。アプリケーション内でこの編集を行うためのピースを開発する必要があります。
全部をロードせずに大量のデータ（おそらくGBの範囲）の編集を処理するための良い方法を決定しようとしたところ、Audacityは大きなファイルを非常にうまく処理できることがわかりました。Audacityはオープンソースであるため、このような状況で私にとって優れた教育ツールになると思いました。しかし、私は自分自身を輪になってコードを調べ始め、今では完全に混乱しています。
私はこの質問から2つの結果を期待しています：
ファイル全体をロードせずにこの編集を処理するための良い方法。私は、データを編集しながらロードし、オンデマンドでキャッシュすることを考えました。
Audacityがそれをどのように行うかの説明。
私はC＃と.NETを使用していますが、回答をその環境に結合する必要はありません。
いくつかのトリックにより、編集がより簡単かつ迅速になります。
ユーザーが行XまたはタイムスタンプTにジャンプしたい場合、改行と文字を数えてファイル全体をスキミングしたくありません。データをスキムし、レコードを作成します。たとえば、50行ごとに、バイトオフセット、文字数、および行番号を記録します。このデータは、ハッシュテーブル、ツリー、または順序付きリストに保存できます。次に、ユーザーがファイル内にジャンプすると、最も近いインデックススポットを見つけて、要求されたポイントが見つかるまでそこから読み取ることができます。この手法は、1文字あたりのバイト数が異なるUnicodeを使用する場合に特に便利です。ファイルが非常に大きい場合、完全なインデックスがメモリに収まらない場合は、インデックスポイントを制限してより広い間隔で配置するか、インデックスを一時ファイルに保存することをお勧めします。
Harveyが提案したように、変更はメモリに（diffとして）のみ保存し、入力から出力へのストリーミングによって保存されたときにファイルに適用します。ツリーまたは順序付きリストが役立つ場合があるため、入力から出力に書き込むときに変更を加える必要がある次の場所をすばやく見つけることができます。
変更が大きすぎてメモリに収まらない場合は、別の一時ファイル（おそらく元のフォルダと同じフォルダ）で変更を追跡することをお勧めします。この変更ファイルに新しい変更を追加して、変更の継続的なリストを書き続けることができます。保存するときは、一時ファイルを削除する前に、変更リストを読み、適用する変更の最終リストを作成します。パフォーマンス上の理由から、変更ログファイルの書き換えを避けることが役立つ場合があります。代わりに、その最後に追加し、保存を実行するときに冗長な編集やキャンセルした編集を削除してください。
興味深い事実：変更ログに使用するのと同じ構造を使用して、Undo/Redo情報を提供できます。
サウンドファイルは基本的にデータストリームですよね？したがって、実際にはファイル全体を一度に処理する必要はありません。Audacityユーザーは、いつでもその大きなファイルの小さなスニペットのみを操作できます。
仮に、1秒のサウンドスニペットを大きなサウンドファイルに追加する場合、実際には、保存する必要があるときにファイル全体を処理するだけで済みます。その時点で、前、1秒のスニペット、および3つの部分をつなぎ合わせます。後。したがって、実際にメモリに存在する必要があるのは、1秒のスニペットと、スニペットの前後のサウンドのごく一部だけです。
したがって、保存するときは、たとえば一度に64メガバイトのファイルを読み取り（本当に積極的な場合）、挿入ポイントに到達するまで、それを一時ファイルにストリーミングします。次に、1秒のスニペットをストリーミングし、元のファイルの残りをストリーミングし、一時書き込みファイルを閉じ、元のファイルを削除し、新しいファイルの名前を元のファイル名に変更します。
もちろん、これより少し複雑です。たとえば、保存する前に複数の編集が行われたり、元にバッファがあったりする場合があります。しかし、Audacityは、使用可能なRAMの量によって、保存されていない編集の複雑さを制限されていることをほぼ保証できます。