| MAP | PageMixer ドキュメント > PageMixer とは何か [ <| 1| 2| 3| 4| 5| 6| 7| > ] |
"性能" に関する JSP、XMLC および PageMixer の違いは、 以下の通りです。
| ---- | JSP | PageMixer | XMLC |
|---|---|---|---|
| ページデータ | コンパイルされたページに埋め込まれた "String" |
"Token" 列 |
DOM ツリー |
| ページデータ共有性 | 有 | 有 | 無 |
| ページデータ生成コスト | --- | --- | 高 |
| 処理の定義方式 | Java コード（JSP 埋め込み） | クラス
（シーケンスに対する "Filter"） |
クラス（DOM 処理） |
| ページ処理の共有性 | 有 | 無 | 有 |
| 処理要素生成コスト | --- | 低 | --- |
| HTML ページ描画コスト | 低 | 中（中間オブジェクトが不要） | 高（DOM ツリーの走査） |
| 新規ページ生成コスト | 低 | 中（あるいは低） | 高 |
PageMixer におけるコスト削減策や、 現在の設計を採用した理由に関する詳細は、 "設計ノート" を参照してください。
"ページデータ" は、 各フレームワークにおけるページデータの表現形式です。 ここでは主に、最終的な HTML ページイメージのデザイン要素に着目しています。 そして、 "ページデータ共有性" は、 一度生成されたページデータを、 それを変更するかもしれないスレッド間で安全に共有できるか否かです。
JSP の場合、
ページデータは、
JSP ファイルからコンパイルされたクラスに埋め込まれた
"String" となりますので、
その共有は可能です。
XMLC の場合、 ページデータは、 HTML ファイルからコンパイルされたクラスによって生成される "DOM ツリー" です。 生成クラスは勿論共有可能ですが、 変更を加える者同士では木構造を安全に共有出来ないことから、 生成クラスのインスタンス（の一部）である "DOM ツリー" は共有できません。
PageMixer の場合、
ページデータは
HTML に由来するオブジェクトにより生成される "Token 列" です。
"Token" は HTML ページを表現するための最小要素です。
HTML ページにおける "タグ" あるいは "text" と考えて結構です。
HTML ページの改変は、"Token" 列の改変に他なりませんが、
UNIX フィルタコマンド（例： "grep"/"sort"/"uniq" 等）
が入力源を改変しないのと同様に、
"Token" 列の改変は、
元になる "Token" 列の改変とはなりません。
そのため、 ページデータ（正確には、ページデータ生成オブジェクト）は、 PageMixer においては共有可能です。
前述のように、 XMLC フレームワークでは、 HTML ページデータをスレッド間で共有することが出来ないので、 処理の度にそれを生成しなければなりません。
XMLC フレームワークでの HTML ページの表現形式は、 "DOM ツリー" を作り上げるために、 多くのオブジェクトを生成しなければなりません。 例えば、 "このページ" は、 XMLC フレームワークにおいては 500 以上のオブジェクト生成を必要とします。
XMLC のリリースノートによると、 XMLC は "レジ−（lazy）DOM" 機構によって、 データ生成のコストを低減しているとのことです。 "ノードのデータ" は共有可能かもしれませんが、 "ノードの構造" が共有可能であるようには見えません。
"処理の定義方式" に関しては以前の節で説明しています。
"ページ処理の共有性" は、 ある処理要素を処理スレッド間で共有可能か否かです。
JSP の場合、 "処理" は JSP ファイルからコンパイルされたクラスの、 埋め込み Java コード部分ですので、 共有可能（正確には、マルチスレッド非安全コードを含まなければ、です）ですし、 共有可能である点は、XMLC でも同様です。
しかし、PageMixer の場合、
"処理" は "Token" 列における自身の文脈情報を認識するために、
状態を持たなければならないため、
マルチスレッド安全性を持っていません。
前述のように "処理" が共有できないため、 PageMixer フレームワークでは、 処理毎にそれを生成しなければなりません。
しかし、非常に細かい単位に処理を分割したとしても、 高々 50 前後のオブジェクトの生成をするだけですので、 そのコストは左程高価ではありません。
2版以後の PageMixer はそれに加えて：
Filter インスタンスの再利用性の向上
"*Watcher" インタフェースが変更されました。
Filter インスタンス生成回数の低減
PageMixer が提供する表示用 Servlet 基底クラスを用いることで、
Filter 生成回数を高々スレッド個数回に低減させることを、
容易に実現できます。
"HTML ページ描画コスト" は、 内部表現形式から HTML ページとしての HTTP 応答バイトストリームへと変換するコストです。
JSP の場合、 殆どの部位がコンパイル済みクラス中に "String" として保持されているため、 変換コストは非常に低いです。
XMLC の場合、 HTML ページの描画には、 それを表現している DOM ツリーの全走査が必要であり、 且つ DOM ツリーが非常に多数のオブジェクトから構成されているため、 描画コストは非常に高いです。
PageMixer の場合、
XMLC と同様に、
多くの Java オブジェクトの集合として HTML ページを表現しています。
しかし、
中間的な "String" オブジェクトの生成を、
低減するように設計されているため、
描画コストは左程高くありません。
"新規ページ生成コスト" は、 新しいページを生成するための総合的なコストです。
これまで述べてきたように、 "ページデータ" および "処理" を共に共有可能なことから、 JSP はコストの面から見た場合は最善のソリューションです。 "ページデータ" の生成および描画コストが高いことから、 XMLC は（少なくとも私の計測では） ３つの中で一番良くないソリューションです。
| MAP | PageMixer ドキュメント > PageMixer とは何か [ <| 1| 2| 3| 4| 5| 6| 7| > ] |