UTF-2000 実装では処理対象とするすべての文字の知識を文字属性として保持 しなければならないために、符号化文字モデルに基づく従来型の文字処理系に 比べて多くの記憶資源を必要とする。
XEmacs UTF-2000 では文字属性データベースは define-char 形式の Emacs Lisp プログラムとして表現され、文字属性データベース全体を読み込んだ状 態の記憶イメージをダンプした実行形式を作り、そのダンプされた実行形式を 用いる。このため、XEmacs UTF-2000 のダンプ後の実行形式の大きさと元となっ た XEmacs-Mule の実行形式の大きさの差は文字属性データベースを保持する ための記憶資源の大きさを意味している。
初期の XEmacs UTF-2000 は文字属性データベースの保持するための機構の効 率化が十分でなかったこともあり、i386 アーキテクチャ上の Linux において 当時のXEmacs-Mule の実行形式が約 10 MB であったのに対し、約5万字分の文 字データを保持した状態で実行形式が 40 MB を越えるようになった。その後、 文字データを保持する機構を改良し、記憶効率を向上したため、最近のXEmacs UTF-2000 では約7万字分の文字データを保持した状態で実行形式は約27 MB と なっている。
このように、主記憶上に文字属性データベースを保持する方法は多くの記憶資 源を要するという点で問題がある。そして、通常の利用で必要となる文字は数 百から数千であり、必要とする文字属性も限られているということを考えると、 文字属性データベース全体をダンプするという方法は望ましくないと考えられ る。
文字属性データベース全体をダンプする方法のもう一つの問題点は、UTF-2000 実装と文字属性データベースが不可分になってしまうことである。つまり、異 なる UTF-2000 実装間で文字属性データベースが共有できないことを意味する。 また、UTF-2000 実装の開発と文字属性データベースのメンテナンスは非常に 性質の異なる作業であるにも関わらず、両者を統合した形でソースファイルを 管理しなければならない。
このようなことを考えると、UTF-2000 実装と文字属性データベースは分離し た方が良いと考えられる。すなわち、文字属性データベースは UTF-2000 実装 の外部にあるデータベースに保持し、UTF-2000 実装において外部データベー スから処理に必要な分だけデータをロードするようにする訳である。
このような考えに立ち、本プロジェクトでは XEmacs UTF-2000 において外部 の文字データベースを利用するための機構を開発した。本章ではこの機構に関 して概説する。
現在の XEmacs UTF-2000 では文字属性データベースは属性毎のデータ構造 (char-id-table) に分けて保持されている。このchar-id-table は文字 id か ら属性値を索くためのデータ構造であり、属性値として任意の Lisp オブジェ クトが格納できる。文字属性名と char-id-table の対応はハッシュ表によっ て管理されており、これにより文字属性名からその属性値を索くことができる。
4.2 節および 4.2 節で述べたよ うに、符合位置属性は coded-charset での復号処理に利用されるが、これは char-id-table を逆索きすることに相当する。復号処理は重要な処理でありこ の高速化のために、coded-charset での符合位置から文字オブジェクトを索く ためのデータ構造 (decoding-table) も用意している。これは 1 byte 毎に分 割した符合位置を用いた入れ子上の配列で実現されている。
XEmacs UTF-2000 において外部データベースから必要な時に情報を獲得するこ と (lazy-loading) をするためには、char-id-table および decoding-table に値が存在しないことを示す印が必要である。このために、記憶空間中に値が 存在しないことを示す特別な Lisp オブジェクト Qunloaded を導入 した。すなわち、char-id-table および decoding-table を索いた時に得られ た値が Qunloaded であれば外部データベースから情報を獲得しなければなら ないことがわかる。そして、この時、外部データベースから情報を獲得するこ とができれば、Qunloaded をその結果で置き換えるとともに、その獲得した値 を返す訳である。
XEmacs は Berkeley DB のような属性値を保持するための単純なデータベース を抽象化した database 機能を持っている。本プロジェクトではこ の機能を利用した文字属性データベースの外部化機能を実現した。現在のとこ ろ、動作確認は Debian GNU/Linux (sid) における Berkeley DB Version 3 でのみ行なっている。
char-id-table および decoding-table は
『文字属性データベースのルート』/『鍵の種類』/『値の種類』というファイル名のデータベースに対応付けられる。
ここで、『鍵の種類』 はその情報の鍵の符号化法を表す。例えば、 char-id-table の場合、鍵の符号化法は XEmacs UTF-2000 の文字 id なので、 それを表す名前 system-char-id が 『鍵の種類』 となる。 decoding-table の場合 coded-charset の名前が 『鍵の種類』 とな る。例えば、ascii の場合 『鍵の種類』 は ascii となる。
『値の種類』 はその属性の名前に対応付けられる。char-id-table の
場合、文字属性の名前が用いられる。ただし、属性名にファイル名として用い
ることができない文字が含まれていた場合、Emacs Lisp における
\-quoting を行なう。また、decoding-table の場合、
system-char-id を用いる。
以下に幾つか例を示す：
『文字属性データベースのルート』 を /usr/local/libexec/char-db/ とする時、
外部データベースからの文字データの獲得は必要な時に自動的に行なわれるが、 記憶空間中の文字データと外部データベースの入出力を制御するために幾つか の API を拡張した。
関数 save-char-attribute-table (attribute)文字属性 attribute のすべての値をこの属性に対応付けられた 外部データベースに保存する。
対応付けられた外部データベースが存在しない場合、何もしない。
関数 save-charset-mapping-table) (coded-charset)coded-charset の decoding-table を対応付けられた外部デー タベースに保存する。
対応付けられた外部データベースが存在しない場合、何もしない。
関数 reset-char-attribute-table (attribute)文字属性 attribute に対応付けられた外部データベースが存在 する時、すべての属性値を消去し、外部データベースから読み込める状態 にする。
TM 5800 上の Debian GNU/Linux (sid) において、約7万字のの文字定義を持つ XEmacs 21.2.43 UTF-2000 のダンプ後の実行形式の大きさが 27 MB (strip 後 22 MB) であるのに対して、lazy-loading 版の実行形式の大きさは 15 MB (strip 後 10 MB) となった。ちなみに、XEmacs 21.2.43（mule 付き）の実行 形式の大きさは 10 MB (strip 後 6 MB) である。
lazy-loading 版の実行形式の大きさがなお XEmacs-Mule よりも 5 MB 程大き いのは、XEmacs-Mule から引き継いだ Emacs Lisp code において、 coded-charset を鍵とした char-table が多用されているせいだと考えられる。 XEmacs UTF-2000 では char-table は char-id-table で実装されており、 coded-charset を鍵にして値を設定した場合、その coded-charset に属する すべての文字に対して値を設定するようになっているため、必要な記憶量が膨 らむと考えられる。また、char-table は文字属性と異なり外部データベース に対応付けられていないため、lazy-loading ができないのである。よって、 この点を改良すれば lazy-loading 版 XEmacs UTF-2000 の実行形式の大きさ を XEmacs-Mule と同程度にすることができると考えられる。