データ構造をより詳しく記述すると下図の様になる。そのまま利用すべきである。そのためには継承または委譲を使用する。拡張したものになっているので、クラス化して利用すべきである。編集可能バッファからはそれらを委譲で利用するようにした。それらのクラスはポリシーとして編集可能バッファに渡すようにした。処理速度(MB/sec)の計測結果を一覧にしたものを下表に示す。本来ランダムアクセスのための機能である。パフォーマンス計測してみる。Bufferファイルをオープン後、先頭の100MBについて、100バイトごとに1バイト削除・挿入・置換する時間を計測。挿入処理はバッファメモリ拡張を行うので、その分削除より時間がかかる。置換処理はデータを上書きするだけなので、削除・挿入より高速になる。メモリ容量以上の編集を可能にする。様々なスワップアウトアルゴリズムが存在する。本実験では、サイズが同一の、書き込み用ブロック、読み出し用ブロックをそれぞれひとつずつ用意することにした。書込用ブロックサイズは読出用ブロックサイズの整数倍であればよい読み出し用ブロックは先のリードオンリーバッファと同じように最後にアクセスされた部分のみをキャッシュすることとした。これは、追加バッファへのアクセスが局所化されている場合には問題ないが、そうでないとパフォーマンス低下をまねく。追加バッファへのアクセスが局所化されるかどうかは編集状態に依存する。}ファイルをオープン後、先頭の100MBについて、100バイトごとに1バイト削除・挿入・置換する時間を計測。処理時間の計測結果を下表に示す。MB/sec)考察スワップアウトを行う場合と行わない場合で、本実験ではほとんど差異はでなかった。スワップアウト処理そのものが実行される頻度が少ないためと考えられる。回の書出しが行われる。バッファとのパフォーマンス比較を行う。置換し、結果を別ファイルへ書き出すものとする。総合評価補足として、空のバッファに上記のトライアングルパターンを書き込むのに要する時間も計測した。パフォーマンス計測結果は以下の通り。最大1G程度しか読み込むことができないが、仮想バッファにより最大4Gまで取り扱い可能になった。シーケンシャルアクセスを高速化する必要があると考えられる。追加バッファの書出しブロックサイズを指定可能にするのも効果的かもしれない。さいごにまとめ:最大容量4GBのバイナリエディタ用仮想バッファのインタフェースを決め、実装、パフォーマンス計測を行った。見通しがよく拡張性に優れたクラス設計を実現できた。ピーステーブルデータ構造は、バッファを仮想化するためのよいデータ構造である。比べると低速なケースもあるので、高度なアルゴリズムの採用を含めたパフォーマンスチューニングが必要。複数の方法で実装を行ったクラスに対して、ランダムな操作を行い、結果を比較するのは、テスト自動化としていい作戦。ご清聴、ありがとうございました。