Jeans CMS 製作日記自分のための次世代CMS製作メモ

あるいは、動作が変更される機能。

適宜、更新。

<NucleusにあってJeansに無い機能 のつづき>

４つの方法を用い、スピードを比較した。ここで用いているデータは、およそ２５０個のアイテムがすでに挿入されている、Nucleus-SQLiteのnucleus_itemテーブルを用いた。

方法１：すべてのアイテムのid,title,timeを一旦メモリに取り込んでおいて、その後に処理。

方法２：方法１と同じだが、sqlite_array_query を使用。

方法３：先の記事で一番最後に述べた方法。

方法４：クエリーを３回実行。一回目であるアイテム、２回目で前を、３回目で後を取得。

結果（それぞれの方法にかかった秒数で表示）

Method1: 0.018667936325073
Method2: 0.015633106231689
Method3: 0.0060269832611084
Method4: 0.00052618980407715

結局は、もっとも単純だと思われる４の方法が一番早かった。SQLのクエリーを複雑に記述する『技』におぼれる弊害が現れているということか。

<あるアイテムと前後のものを同時に取得 その２ のつづき>

表題のためのクエリ：

SELECT  i.inumber as thisid, j.inumber as previd, k.inumber as nextid 
FROM nucleus_item as i,nucleus_item as j,nucleus_item as k 
WHERE i.inumber=10 AND j.itime<=i.itime AND i.itime<=k.itime 
AND NOT (i.inumber=j.inumber OR i.inumber=k.inumber) 
ORDER BY TIMEDIFF(j.itime,k.itime) DESC LIMIT 1

クエリー実行 0.0021 秒

ただし、最新の記事もしくは最古の記事でこれを行うと、失敗する。

<あるアイテムと前後のものを同時に取得 のつづき>

Jeans CMSの骨格ともいえるクラス郡のコードがほぼ完成。もっとも大事なクラスは、

coreクラス：Jeans初期化・htmlspecialchars互換のサニタイズルーチン・デストラクタ管理
sqlクラス：SQLite, MySQL, PostgreSQLのラッパークラス
jitクラス：スキン変数・テンプレート変数のコンパイル

の３つのクラスで、これに順ずるものは、

memberクラス：ログインを管理
actionクラス：アクションを管理
refreshクラス：スキン変数・テンプレート変数・アクションを処理するメソッドを、データベースに登録

の３つ。これら６つのクラスを、ハウスキーピング遺伝子（house keeping genes/house keeping jeans）と呼ぶことにする。

<骨格部分がほぼ完成 のつづき>

スキン変数の<%blog%>は、最も重要な機能の一つ。今のところ次のように記述しているが、変更の余地は大いにあるのでメモしておく。

<スキン変数&lt;%blog%&gt; のつづき>

jit.php のinit()で、次の命令によりskinvar, templatevarのテーブルが一気に読み込まれる。

self::unbuffered_query('SELECT subtype, name, method FROM jit_skinvar WHERE type=<%1%>',$type);
$data=array();
while($row=self::fetch_array()){
    $data[$row['subtype']][$row['name']]=$row['method'];
}

これに要する時間は、クエリーの発行に約１５０μ秒、フェッチには一件当たり約７μ秒である。jit.phpでは、コンパイルの際にすべてのskinvarデータが必要だから、上記のように一度に読み込むのが最も効率が良い。一方で、個々にSQLクエリーを発行したほうが効率が良い場合もある。例えば、一つのページを表示する際に、テーブル中の一つのデータしか必要でないときなど。このケースでは、quickQuery()メソッドで一つ一つ呼び出すのが良い。

では、その中間ではどのように処理すればよいか。例えば、メンバー情報などは一つの例である。多数のメンバーが居る際、一つの表示ページ中に記事の著者が一人の場合はquickQuery()の方が早い。他方で、複数の著者の記事を含むページを表示する際は、quickQuery()の方が早い場合と、一気に読み込むほうが早い場合とがある。

<SQLテーブルの値を一気に読み込むべきか、個々にクエリーを発行するべきか。 のつづき>

現在の仕様では、新しいクラスが呼び出されたときに、init()メソッドが存在すればそれを呼び出す仕組みになっている。クラスによっては、init()メソッドは必要ではないのであるが、その場合は、init()メソッド呼び出しの際の命令でWarningが発生する（@を用いているので、表示されない）。

このようなケースに、空の内容のinit()メソッドを記述しておいたほうが早いのか、何も記述しないほうが早いのか、調べてみた。

<クラスに空の内容のメソッドを持たせるべきか持たせざるべきか のつづき>

スキン変数<%blog%>を作成して、テストしてみた。新たにblog.phpを作成したが、これは将来的にskin.phpに統合する可能性が高い。

<テンプレート機能の動作を確認 のつづき>

スキンパースの、<% %>→<?php ?>変換部分をjit.phpとして独立させ、テンプレートのパースルーチンもここに加えた。

アイテムのパースは、ここでは行えない。というのは、コンパイルされたindex.phpではスキンパース・テンプレートパースはすでに行われているが、アイテムのパースは表示するごとに行う必要があるためである。アイテムのパースに同じルーチン（jit.php）を呼び出すと、スピードの上で効率が良くない。

そこで、アイテムパース時に必要なitemvarの情報は、各アイテムに埋め込むことにして、アイテムパース部分はjit.phpから独立させることにする。例えば、

testitemvar|class::method/testitemvar2|class::method/

などの文字列を記事保存時にアイテム用のテーブルに保存しておき、アイテムをパースする時に、この情報に従ってpreg_replaceする。

…かな？現在のところ、jit.phpは１７０行ほどだから、これをskin.phpに戻してアイテムパースもここから行うほうがいいのかも。

考え中。

<jit.php のつづき>

手元の環境で調べたところ、PHPコードのパース（JITによるコンパイル）には、平均して一行あたり約２．５μ秒かかっている。一方で、一つのクラスをファイルから呼び出すのに、最低５００μ秒が必要。例えば、１００行からなるファイルだと、２．５×１００＋５００＝７５０μ秒。現在までに８つほどクラスを作成したが、コードのパースにかかる時間は、ほぼこの計算値と一致している。

どの機能を別のクラスに分けて、どの機能は分けずに同じＰＨＰファイル内に置くかの決断が難しい。別のクラスに分けることで５００μ秒のロスがあるわけだから、クラスを分ける場合、このロスを解消できるだけの見返りが必要である。あまり細かくファイルを分けてしまうと、かえってスピードが遅くなってしまう。

<別ファイルに分けるべきか、分けざるべきか のつづき>