recentプラグインでrecent.datを有効活用していない†
- ページ: BugTrack2
- 投稿者: teanan
- 優先順位: 普通
- 状態: 完了
- カテゴリー: その他
- 投稿日: 2006-01-13 (金) 03:19:56
- バージョン:
メッセージ†
cache/recent.dat に各ページの時刻情報があるのに、経過時間を計算する際は get_filetime の値が使われます。既知のとおり、get_filetime は遅いので recent.datの値を有効活用しましょう。
- cvs:plugin/recent.inc.php (1.19)
- 経過時間の計算にrecent.dat の値を使用するようにしました。これにより、recentプラグインでは $show_passage の値を参照しなくなります。 -- teanan
- recentプラグイン内に PLUGIN_RECENT_SHOW_PASSAGE を新たに定義しました。これを FALSE にすることにより、ツールチップの表示自体を無効にできるようにしています。これまで $show_passage を無効にすると、ページ名だけのツールチップが出てきていましたが、これも出なくしています。 -- teanan
- こちらのコメントと、コミットされたコードが対応していない気がして、じっくり見たところ関数の変更に気付きました。また定数に関しても記載がなかったため、それぞれ作業の要点としてコミットログに追記しました -- henoheno
- cvs:plugin/recent.inc.php (1.21)
- 「副作用として $show_passageを見なくなってしまう」という部分はこの件とは関連がありませんので、こちらは直しますね :) なおrecentだけのon/offも試してみましたが、$show_passage の値で全体が連動してくれないのは使い勝手が落ちるようです。(recentがtitleを表示する事の利点は、ページ名が隠れるほど長い場合にtool tipを出してフォローしてくれる、という点にあります) -- henoheno
- cvs:lib/file.php (1.49)
- cvs:plugin/recent.inc.php (1.23)
- cvs:plugin/rss.inc.php (1.18)
- 現状、recent.datが数百ないし数千行あるとき、recentやrssプラグインがそれを数百ないし数千行読んでしまっています。これは単純に無駄な処理ですので、必要最小限の行をだけを読む関数 file_head() を作成した上で、これを使う様に修正しました。負荷がrecent.datの行数に影響されなくなるため、特別ページ数が多いWikiに関してはこの分のオーバーヘッドが無くなります。とりあえずbuffer sizeは8192固定。 -- henoheno
- お疲れ様です。フォローありがとうございます*1。 -- teanan
- いえいえ :) recent.datの時刻を見ていないというのは確かに勿体無い話でした。他にも似たような話題は色々あるわけで、使える日々の時間がそうあるわけでもないですから、ざくざくナタをふるいながら進む位が丁度いいです。 -- henoheno
- 項目としては完了にしておきます。 -- henoheno
さらに踏み込んで・・†
- ページを更新すると、cache/recent.dat と一緒に RecentChanges というページも更新されます。内容は同じなので、RecentChangesを recent.dat から作れるようにすると、更新時の処理が簡略化できると思います(そもそも、同じ情報を2個所に持つ意味もないと思いますので)。 -- teanan
- recentプラグインでRecentChangesと同じ表示ができるように引数を追加し、RecentChangesからは recentプラグインを呼び出すだけにすると良いと思います。 -- teanan
- 私は更新時の負荷が下がるよりも、より頻度の高いと思われる参照時の負荷が下がった方が嬉しいです。2箇所に持っている理由はBugTrack/183を参照して下さい。 という事で（？）recentプラグインでRecentChangesを表示するのは反対したい気分なのですよ。 -- にぶんのに
- なるほど、以前に議論になっていたのですね (^^; ありがとうございます。 -- teanan
- ただ、BugTrack/183は filemtime を使った場合との比較になっているようです。recent.dat から RecentChangesを作ろうとしてますので、負荷はそれほど高くないと思っているのですが・・・ -- teanan
- 確かに。極端な差は出ず、あとは個々の更新頻度次第で望む結果が変わりそうですね。で、別案になりますが、例えば更新時処理の簡略化はRecentChangesを更新しないオプションを追加して、RecentChangesからはBugTrack2/45を呼ぶのは駄目ですかね？ BugTrack2/45を取り込んで欲しかったり、デフォルトを従来通りRecentChanges更新する方式にしてリリース時の移行説明で楽しよう、とか動機はえらく不純ですが。 -- にぶんのに
- これまでのRecentChangesの動作を変えてしまうのは勇気がいりますので、デフォルトで今までの処理を残しつつ、オプション対応することになると思います :) BugTrack2/45 については、取り込むには少し大掛かりになりそうですので、今のところ(私は)手をつけていません。私の追加改造 も一緒に入れたいところですが、実はまだ改善ネタを残していたりします (^^; -- teanan
- そう、BugTrack2/45の取り込みはとても大掛かりになりそうなんですよ。まずはこの実装でfeedが必要としているrecentの見直しから始めなければなりません。GW中にできるかどうか・・・ -- henoheno
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
