ブログ - XCL [2.1.5] ${Dirname}_Module に関する考察 (その2)
というわけで、mModuleConfig の取得をオンデマンドに行う実験をしてみた。
■config 取得を遅らせる実験
■config 取得を遅らせる実験
まずは Legacy_AbstractModule の mModuleConfig を private に変更する。
コンストラクタでの mModuleConfig 取得をやめる。
getModuleConfig() を修正し、mModuleConfig を取得していなくてconfig が存在すれば、mModuleConfig を取得するようにする。
setModuleConfig() はprivate にする。
■結果
一応それなりに動いているようだ。
カレントモジュールについては、互換性の関係 ($GLOBALS['xoopsModuleConfig'])ですぐに取得してしまうから、動作に支障はないと思う。
カレントでないモジュール(管理側だけということだが)では明らかに getModuleConfig の呼び出しはほとんどなく、事実 config へのSQLが激減した。
■結論
この程度のオーバーヘッドであれば、公開側でも ${Dirname}_Module をそれぞれのモジュールについてインスタンス化してもかまわないのではないだろうか。
もちろんパフォーマンスの問題はSQL問い合わせの量だけの話ではないが...
■宿題
個人的には modules への度重なる問い合わせが気になる...
これは局所的な話では改善できないが、モジュールマネジャーの導入で解決が図れるように思う...
でもちょっと手を入れる範囲が大きすぎるね....
コンストラクタでの mModuleConfig 取得をやめる。
getModuleConfig() を修正し、mModuleConfig を取得していなくてconfig が存在すれば、mModuleConfig を取得するようにする。
setModuleConfig() はprivate にする。
■結果
一応それなりに動いているようだ。
カレントモジュールについては、互換性の関係 ($GLOBALS['xoopsModuleConfig'])ですぐに取得してしまうから、動作に支障はないと思う。
カレントでないモジュール(管理側だけということだが)では明らかに getModuleConfig の呼び出しはほとんどなく、事実 config へのSQLが激減した。
■結論
この程度のオーバーヘッドであれば、公開側でも ${Dirname}_Module をそれぞれのモジュールについてインスタンス化してもかまわないのではないだろうか。
もちろんパフォーマンスの問題はSQL問い合わせの量だけの話ではないが...
■宿題
個人的には modules への度重なる問い合わせが気になる...
これは局所的な話では改善できないが、モジュールマネジャーの導入で解決が図れるように思う...
でもちょっと手を入れる範囲が大きすぎるね....