BugTrack/2080

links_update の処理を見直そう†

重そうな割に有効活用されてなさそうに見える links_update の処理を見直して、処理の効率化を図りましょう。

cache/～.ref: そのページが参照されているページの一覧。 cmd=relatedで表示されるbacklinkそのもの。ページ下部に表示される、related link の表示にも使用される。

do_search (単語検索) を呼んでいる。
- do_searchは全角半角、かなとカナの違いなど微妙な表記のゆれを同一とみなしているが、これによって検索速度が低下する上、不要なページも処理対象となるため*links_updateにとっては*不要な処理である(BugTrack2/171)。
InlineConverterが呼ばれ、もう一度ページの変換処理が行われている。
- AutoLinkでリンクされた部分だけを分けて処理をしているが、その結果が活用されているようには見えない。ページが削除された時に links_delete するため?
- links_get_objects で InlineConverterする際に footnote だけ除外されているのは何故?
links_updateが再帰呼び出しされている。
時刻情報を入れておくと、links_get_related_db でget_filetimeする必要は無いのでは?

$related_link = 0 のときでも links_updateが呼ばれている。
- links_updateを呼ばないようにすると、書き込み時の負荷が軽減されるのでは? *2
ページ削除されたときにファイルが削除されない。→ BugTrack2/47
links_init関数にも同じコードが書いてあるような気がする。
効率的に処理されているように見えない (^^;

バックリンク(related): 「No related pages found.」となる。
map.inc.php: 「Not related from FrontPage」となり、階層が表示されない。
touchgraph.inc.php: 起動時にExceptionが発生して終了する。
yetlist.inc.php: 「未作成のページはありません。」
deleted.inc.php: コメントを外して*3「index.php?cmd=deleted&dir=cache」のように指定した場合に、rel/refが無い全てのページ名が一覧表示される。

AutoAliasから始まった話*4ですが、別の出口が見えてきましたので BugTrack として提案しました。 -- teanan 2005-06-16 (木) 03:50:33
あ、BugTrack2/56で続けた方がよかったのかもですね (^^; -- teanan 2005-06-16 (木) 04:12:46
yetlistがrefを見てます。 -- 2005-06-17 (金) 00:56:01
- おっと、そのとおりですね。ご指摘ありがとうございます。 -- teanan 2005-06-17 (金) 02:03:19
BugTrack2/56は管理者向けの注意事項としてひとまずまとめたものなので、気にしないで下さい :) こっちはこっちで(修正するものの視点で)綺麗にまとまっていると思います :) -- henoheno 2005-06-19 (日) 11:06:59
ref/relが無い場合の各プラグインの挙動を追記。使用頻度から考えると、ref/relを更新しないオプションを設けても良いかも。オプションの設定があれば、これらのファイルに依存しないように各プラグインで対応することも可能ですね。 -- teanan 2006-01-11 (水) 03:33:34
- 各プラグインで対応するよりも、link.phpで抽象化したほうが良さげですね。 -- teanan 2006-01-11 (水) 09:04:48

linksプラグインから呼び出されるキャッシュ更新処理で、メモリ使用量を抑える修正を行いました。 -- teanan 2006-01-12 (木) 17:52:52
- cvs:lib/link.php (1.9)
約2000ページ(ヘルプと同一の内容)の環境で、memory_limit=6M で更新できなかったものが 5Mでも更新できるようになったので、それなりに効果が出ていると思います。 -- teanan 2006-01-12 (木) 18:10:23

total:
today:
yesterday:
now: 1