ls2プラグインは、呼び出されるたびにget_existpages()を呼び出すので、
全体で数万ページあるようなサイトでは、ページ内に何度も#ls2を書くと
無視できないほど遅くなります。
get_existpages()の結果をキャッシュして、複数回呼ばれたときの処理を高速化します。
$ diff -u ls2.inc.php.original ls2.inc.php
--- ls2.inc.php.original 2004-12-05 20:37:37.000000000 +0900
+++ ls2.inc.php 2011-04-01 01:52:35.372269811 +0900
@@ -86,14 +86,18 @@
function plugin_ls2_show_lists($prefix, & $params)
{
global $_ls2_err_nopages;
+ static $s_cached_existpages = null;
$pages = array();
+ if ($s_cached_existpages === null) {
+ $s_cached_existpages = get_existpages();
+ }
if ($prefix != '') {
- foreach (get_existpages() as $_page)
+ foreach ($s_cached_existpages as $_page)
if (strpos($_page, $prefix) === 0)
$pages[] = $_page;
} else {
- $pages = get_existpages();
+ $pages = $s_cached_existpages;
}
natcasesort($pages);
- 全体ページ数2万のあるサイト、#ls2(キーワード) が 45あったあるページのHTML convert time:
コメント†
- 遅かったので対策しました。 -- umorigu
- get_existpages()側でキャッシュすればls2に限らず高速化されるとか... --
- されます。get_existpages()の変更は影響範囲を読めなかったので今回はls2だけにしました。ここ (//www.revulo.com/PukiWiki/Cache/PagenameCache.html) ではget_existpages()内でキャッシュしているようです -- umorigu
- 「影響範囲」というのは「get_existpages()→ページ追加・削除→get_existpages()というケースがあるかも?」という懸念です -- umorigu
- この件は、①全体で数万ページあるようなサイトを引き合いに出しているのに、それを メモリに キャッシュするという富豪的な所と、②ls2のみが対象である(局所解)である という所に抵抗感を覚えます。 -- henoheno
- メモリについては、例えば 32文字/UTF-8で62bytesが10万ページあったとしても、文字列リストの容量は7MBほどですので、富豪的とはいえ問題になるようなレベルのものではないと考えています。ただ、ご指摘を受けて改めて見直してみると、ここで提案した実装は get_existpages() の結果をそのままキャッシュしているので倍ほどメモリを無駄に使っていることがわかりました。(キャッシュには不要な「ファイル名」を含んでいる。)ここは対応したいと思います。2点目、ls2限定にしているのは影響範囲を小さくするためです。get_existpages()の中でキャッシュするすると、get_existpages()を呼び出した後にページ生成をするようなプラグイン(標準添付のものではbugtrackやtracker)のことを考えると、キャッシュ機構をかなり複雑なものにする必要がでてきます -- umorigu
- 「readプラグインが動き始めてからのみキャッシュする」のような動作にできなくもないので、もう少し考えてみます -- umorigu
- パラメータを変えて同一ページで何度も呼び出されるプラグイン(かつ、それぞれの呼び出しでページを列挙する)というのは限られており、標準のものではls2とcalendar_viewer系プラグインです -- umorigu
- ls2の高速化はBugTrack/2438, calendar_viewerの高速化はBugTrack/2446で、同じ実装 (get_existspages内でのキャッシュ)で実現されています -- umorigu