速度的にはまだあまり問題は出てない。

なんかFirefoxとIEで体感速度が違う（FFがもっさりでIEが普通に速い）ので、ちょっと気になってxdebugでprofileしてみた。
大体300ms位。検索で。遅い、とは言えないが・・・。
で、よくよく考えたら開発用なので、config.phpでSmartyが毎回コンパイルするようにforce_compileを有効化してた。
これを切ってみたところ、大体100ms位まで縮まった。一番処理的に重い検索モードでやってみたところでも100ms前後。問題ない。多重アクセスなどはやってないけど、そもそもがあまり激しいアクセスは想定していないので、ちょっとまだそこは未知数。検索・View系であれば殆どDAOもcache経由になるので、ファイルロックは内部的には発生しないと思うし。うー、アクセスカウンタとかつけたらそうも言ってられないかも。あー、拡張子があれだから、Webalizerと相性悪そうだなー。
preg_matchとsubstrが、HTMLの独自タグ解析上大量に呼ばれているけど、時間的にはあまり食ってない。100msのオーダーでも(文字列処理系総合で)達していない。それよりは、Smartyのコンパイル系で、回数はあまり呼ばれていないがなんだかんだで100msのオーダーで食っていたので、そこが無くなった影響はでかいかも知れない。
つまり多分Viewレイヤーでの速度はあんまり気にしなくて良いと思う。多分今後、実際に使ってみてデータ量が増えていった時に、むしろメモリ消費量やDAO/IDXレイヤー(IDXはそんな気にしなくて良いと思うけど)でネックになってくるかも知れない・・・って、そもそもマスタデータ系は3桁オーダーmaxを想定しているからなぁ。4桁レベルは想定してない。そこで問題が出てくれば、yakibiki.netの出番となるだろう。
あとSmarty関連で思い出したのだけれど、$use_sub_dirsと$cache_dirは今回は未使用。動的コンテンツなので、内容が逐次変化する為$cache_dirは使えない*1。また、$use_sub_dirsはWindows環境では上手く動作しない、と公式マニュアルに記述されているし、そもそもSmartyテンプレートの数自体、4桁オーダーには達していない・・・筈。なので、これらは未使用で問題ない、というか使えない。

*1:あー・・・yakibikiモジュールのRawとViewモードについてのみ、限定的に有効かも・・・。でもinvalidするトリガーがなぁ・・・Observerパターン化？