汎用のテキスト エディターを実装する場合 (汎用とは、たとえば、100 ～ 200 MB を超える巨大なファイル (まだ大量であり、 「一般的なケース」の極端な例です))。テキストを 1 つの連続した長いバッファーに格納するだけでは実行できません。これは、挿入/削除でパフォーマンスが低下するためです。
これに取り組む方法はいくつかありますが、それらはすべて、テキストをチャンクに分割する必要があるという事実を中心に展開しているため、私の質問は次のとおりです。今日のコンピューターの能力を考慮すると、最適なチャンク サイズはどれくらいになるでしょうか? 単純な連続バッファに格納するには実際に大きくなり始めているテキスト バッファの実際のサイズはどれくらいですか? 現代のコンピューターは、大量のバイトを移動する速度はどのくらいですか? (わかりやすくするために、ギャップ バッファーは使用できないとだけ言っておきましょう。各チャンクは単純な連続配列になります。)
Eclipse では、ほとんどすべてのエディターが を使用して実装されているGapTextStoreため、単一のギャブを持つ単一のバッファーのみに依存しています。
州の JavaDoc の興味深い部分GapTextStore:
ギャップ管理テキスト ストアを実装します。ギャップ テキスト ストアは、ドキュメントに対する連続した変更が同じ場所にあるという前提に依存しています。ギャップの開始点は、常に最後の変更の場所に移動されます。
パフォーマンス: 再割り当てが必要にならない限り、入力スタイルの変更は一定時間で実行されます。一般に、再割り当てを引き起こさない変更では、約 d の長さの arraycopy 操作が最大 1 回発生します。ここで、d は前の変更からの距離です。a(x) を長さ x の arraycopy 操作のアルゴリズム性能とすると、そのような変更は O(a(x)) で実行され、get(int, length) は O(a(length)) で実行され、get (int) in O(1)。
配列の再割り当てが必要な頻度は、コンストラクターのパラメーターによって制御されます。
一般的なコンシューマ システムは、DDR3 メモリで 10 ～ 30 GB/秒の raw メモリ スループットを達成できます。それは一種の基数です。
私の経験から、Java で 1 秒あたり約 100 MB のメモリ操作を達成するのに問題はないと想定しても安全だと思います (C++ ではおそらく 4 ～ 8 倍の処理が可能です)。そのことから、バッファ サイズが 64kb の場合、1 秒あたり 2^10 操作のようになり、それでも問題ないように思われます。
「ロープ」と呼ばれるデータ構造をよく読む必要があります(もちろん、ロープは一種の重量級の文字列です)。元のSGI STL には文字列と同様にそれらがあり、C++ 標準ライブラリには含まれていませんでしたが、Gnu には拡張機能として含まれています。
「チャンク サイズ」は、実装 ( notes ) ではそのままでは表示されないことに注意してください。