#author("2016-12-03T00:04:27+09:00","","")
#author("2016-12-03T00:05:25+09:00","","")
* なぜページ数が増えると AutoLink は動作しないのか [#pa3df9af]
- ページ: [[BugTrack2]]
- 投稿者: [[bee]]
- 優先順位: 低
- 状態: 提案
- カテゴリー: 本体バグ
- 投稿日: 2016-11-26 (土) 08:50:05
- バージョン:
** メッセージ [#m7dc0e21]
ページ数が増えたとき、AutoLink が原因で正常に動作しなくなると言われている（関連: [[BugTrack2/81]]）。
しかし、AutoLink の何が原因なのかコメントを追っていってもよく分からなかった。
- PCRE の問題？
-- サブパターン数の限界？
- メモリ使用量の問題？
- CPU 時間の問題？
原因はさておき、効率の良い正規表現を生成するライブラリとして Regexp-Assemble が知られている。~
PukiWiki でも henoheno さんが generate_trie_regex() という関数を作成している（1.5 には未マージ）。
- [[開発日記/2009-04-19]]
-- [[BugTrack/502]]
-- [[BugTrack2/311]]
しかし、何が原因なのか分からなければベンチマークも取れないし、改善したか（もしくは悪化したか）確認するのも難しい。~
そこで AutoLink が動作しない条件を調べたい。~
もとい「詳しい人がいたら教えてほしい」という Bug です。
--------
- ニコニコ大百科のタイトルを食わせてみたところ~
"preg_match(): Compilation failed: regular expression is too large at offset 3339719"
という WARNING を吐いてくれました。 -- [[bee]] &new{2016-11-26 (土) 10:54:37};
- www.pcre.org/pcre.txt によると 64K data units を越えてはいけないらしい。 -- [[bee]] &new{2016-11-26 (土) 11:09:41};
- blog-tmtsts.rhcloud.com/135 の方法を試したところ、32765 Byte で私の環境も WARNING が出ました。 -- [[bee]] &new{2016-11-26 (土) 11:11:33};
-- pcre.backtrack_limit/pcre.recursion_limit の設定を一桁ずつ増やしてみたが当然ながら効果なし。 -- [[bee]] &new{2016-11-26 (土) 11:19:18};
- bit.ly/2fitPfD で~
pukiwikiベースのwikiだと日本語名のページは900ページ前後（略）でホワイトアウトして文字が見えなくなる表示上のバグがある
と言われていたのが不思議だったのですが、日本語が 3 バイトでページ名が平均 12 文字程度とすると 900 ページで 32KB を使い切りますね。なるほど。 -- [[bee]] &new{2016-11-26 (土) 11:38:20};
- まあとりあえず preg_replace_callback の戻り値をチェックするようにしたほうがいいですね。ページが真っ白になるのは NULL を素通りさせているせいだと思われるので…。 -- [[bee]] &new{2016-11-26 (土) 11:43:38};
- 意欲的なIssueですね。個人的にAutoLinkは利用していないのですが、よく使われているのでしょうかね。確かにGoogle検索するとこの制限にかかっている人がちらほら見られます -- [[umorigu]] &new{2016-11-26 (土) 22:35:40};
-- コラボレーションツール、辞典、日記などいろんな用途のうち、AutoLink を使いたいパターンは限られているような気はしますね。 -- [[bee]] &new{2016-11-27 (日) 08:28:16};
- preg (PCRE) の代わりに mb_ereg（鬼車）を使う選択肢もあります。鬼車は PCRE のような制限がないらしく普通に動作しました。次は「AutoLink のメモリ使用量が多すぎて何も表示されなくなる」という報告が来ることになりそうですが…。 -- [[bee]] &new{2016-11-27 (日) 08:54:01};
- こんにちは。最新のソースの中にあるgenerate_trie_regex() は元々どなたかが作られた美しい関数を再構成したもので、私が作成したものではありません。AutoLinkには「処理できるサイズを超え(う)る」という設計上の課題があるので、そこを打破できない限り問題は収まらないと思われます。 -- [[henoheno]] &new{2016-11-27 (日) 21:33:56};
-- autolink.dat にただ一つの正規表現を収めることをやめて、何らかの条件で分割した複数個の正規表現を格納する方式に改める必要がある、ということです。 -- [[henoheno]] &new{2016-11-27 (日) 22:58:36};
--- はい。この問題は 1) 正規表現を適切に分割する 2) 正規表現を効率化する 3) 特定の名前空間を除外できるようにするなどしてユーザーが正規表現を短くできる仕組みを作る…といった複数の解決策が必要です。 -- [[bee]] &new{2016-12-01 (木) 11:58:34};
-- おっと、また勘違いをしました。すみません > generate_trie_regex() の件 -- [[bee]] &new{2016-12-01 (木) 11:46:34};
- mb_regを使うだけで改善されるんですか。それはいいですね。副作用を確認しておきたいです -- [[umorigu]] &new{2016-11-29 (火) 07:56:04};
-- 目下最大の障害は mb_ereg_replace_callback() が PHP 5.4.1 以降の関数で、preg_replace_callback() の代替が PHP 4〜5.3 にないという点ですね…。 -- [[bee]] &new{2016-12-01 (木) 12:01:06};
-- すべてのPHPバージョンで同じ機能・制約にする必要はなく、mb_ereg_replace_callbackの有無で処理を分ける方法もあります。例えばbugtrack_listキャッシュはPHP5.4以降のみで動くようにしました -- [[umorigu]] &new{2016-12-02 (金) 08:50:00};
-- 了解です。packagist.org/packages/gobie/regex のベンチマークによれば preg_replace_callback/mb_ereg_replace_callback の性能差はほぼありません。あとは正規表現が長くなれば当然メモリ消費量も増えるため、PHP のメモリーリミットに引っかかりやすくなり、今よりひどい挙動になるのではないか、という懸念があります。 -- [[bee]] &new{2016-12-03 (土) 00:04:27};
- このBugTrackの趣旨とは少しずれますが、今のロジックで改善できるところまではして、それ以上はクライアント側の処理にするのが良いのかなと思ってます。つまりページリストをブラウザに渡して、JavaScriptでリンク作成するような仕組みです。もっとも、数万ページになるとリストだけでMB単位になってしまうので別の工夫も必要になります -- [[umorigu]] &new{2016-11-29 (火) 07:57:14};
-- 別の理由からクライアント側の処理にする必要があると思います。本当は DOM を解析してテキストノードだけに AutoLink を適用するべきなのですが、現在の AutoLink はかなり Hacky に動いています。正規表現でマッチさせる部分はサーバー側で行いつつ、実際に適用するのはJavaScript で行うようにしたほうが確実です。 -- [[bee]] &new{2016-12-01 (木) 12:09:57};
-- JavaScript に頼ると携帯で AutoLink が使えなくなるという問題も一応指摘しておきます。 -- [[bee]] &new{2016-12-01 (木) 12:12:42};
-- 了解です。packagist.org/packages/gobie/regex のベンチマークによれば preg_replace_callback/mb_ereg_replace_callback の性能差はほぼありません。あとは当然メモリ消費量が増えるため、PHP のメモリーリミットに引っかかると今よりひどい挙動になるのではないか、という懸念があります。 -- [[bee]] &new{2016-12-03 (土) 00:04:27};
#comment
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
