使って実装したものでパフォーマンス計測した結果を報告する。ログなどの巨大ファイルの内容を参照・編集したいという要望が増えてきた。ファイル内容をすべてメモリ上にあるバッファに読み込んでいるため巨大ファイルを編集どころか読み込むこともできない。いつどの時点で内部文字コードに変換するかを決めなくてはいけない。ピーステーブルは行に関する情報を保持しないが、行番号ジャンプや編集フラグ処理などで行単位処理が必要。どのように行情報を保持し(または保持せず)、処理をするかを決めなくてはいけない。最後にスワップアウトを行うフルスペックのものを実装・評価する本稿では本格的なパフォーマンスチューニング・undo/redo機能実装は行わず、5月中旬以降の課題とする。バッファテキストエディタは、簡単に言うと、シーケンシャルなテキスト情報を保持し、ユーザの指示により内容を表示、修正するプログラムである。ユーザの指示を解釈し、適切なメソッドを呼び出すオブジェクトを導入する。前者をバッファ(エディットエンジンとも呼ばれる)、後者をUIオブジェクトと呼ぶ。バッファとは1次元的に並んだ文字を管理するクラスである。車で言えばエンジンにあたるようなもので、テキストエディタの最も重要なモジュールのひとつである。シーケンスのデータ構造はクラスにより様々で、それによりバッファクラスの特徴・性能が決まる。リードオンリー仮想バッファ最も簡単なリードオンリーな仮想バッファを実装し、パフォーマンス計測を行ってみる。ファイル先頭から末尾までをシーケンシャルアクセスするのに要する時間を計測する。テキストエディタ用バッファにおいて、もっとも重要なのはシーケンシャルアクセスのパフォーマンスである。機能を実装する必要がない。利用可能なメインメモリ容量以上のテキストファイルの内容を参照するために、ファイル全体をメモリに読み込むことは行わない。データ構造:(デフォルトで)4096バイトのキャッシュバッファ(ビューとも呼ぶ)を用意する。参照された部分をキャッシュに読み込むだけとする。テキストエディタではアクセスされる部分は局所化されており、このような単純なアルゴリズムで問題ない。}キャッシュバッファの実装方法としては、以下の方法が考えられる。}計測内容:ファイルをオープンした後、先頭から最後までをシーケンシャルにアクセスするのに要する時間を計測する。キャッシュが効いている場合とそうでない場合でタイムが異なるので、2回続けて計測する。画面表示を繰り返し行う場合はキャッシュが効いた状態となる。一括オープンした場合も計測した。4,043KB/S結果・考察:MMFは非常に高速だが、メモリに一括読み込みできる場合に限られるし、仮想メモリ空間をファイルサイズ分消費する。未計測キャッシュが効かない場合の速度はほとんど変わらないが、キャッシュが効いていると半分程度の速度になる。HDDキャッシュが効いている場合はオーバヘッドを無視できなくなるということである。仮想関数コールのオーバヘッドでそれほど高速にはならないと考えられる。シーケンスでテキストシーケンス全体を表現する。本来は追加バッファの一部を外部記憶装置にスワップアウトするのだが、この版ではその処理を行わない。オリジナルバッファ/追加バッファ、スパンに含まれるデータサイズ、スパン先頭位置のバッファ内オフセット情報を持つ。内オフセットを計算する。次にオリジナルバッファまたは追加バッファを参照してデータを取り出す。バッファを参照するときはリードオンリー仮想バッファと同じ処理を行う。対応するSpanを探す。}バッファ内インデックスから対応するスパンを検索する処理時間は、スパンを格納するデータ構造に依存する。