5月30日

2011/5/30作成

海星からこのテキストの感想がきてた。よかった反応があって。分かりにくいところがあるという指摘があったんで、その点は加筆しよう。反応を得られてよかったかな。

午前中、だらっとlintに基づく修正を少し。しかし終わらんな、この作業。なんつうか、警告件数の多いものだけに絞って修正作業をするようにしたほうがいいのかも。

午後、寝る。そりゃ寝不足だもんな。ぐー。

FreeBSDの環境を構築しなおす。ディスク容量が足りなくなってきたんで。ディスクを足すだけならVMwareで出来るんだけど、そうするとパーティションが別になって不便になるんで。今後も使い続けるだろうから、早めに一新しておいた方が利便性があがるだろうと判断。

INETNER Watchのバックナンバーを出典にして、「Adobe Contribute」と「Flash Player」のバージョン履歴を少し加筆。

海星から、プログラムの修正内容が具体的でないという指摘を受けたので、修正履歴を見ながら書いてみる。ほんとは修正したそれぞれの箇所に書けばいいんだけど、どこがどの修正なのかまで細かく覚えてないので、ここでまとめて。既に書いた内容とも被るけど。

まず分かりにくかったという指摘のあったデータのサイズ。元になるデータはノートと利用者ページを除いたpages-articlesというアーカイブの5月7日版なんだけど、ファイルサイズが5.3GB、行数が9000万行、記事数が150万というもの。これにlintをかけた処理時間が、初期バージョンで約28年(予測)。最終版が6時間くらい。lintをかけた最終結果のレポートが、ファイルサイズが1GB、行数が2000万行、対象記事数70万件。

高速化にあたって行ったのは、だいたい次の通り。
・実行時にはuse strict; use warnings;を外す。
・関数間で引き渡される変数は基本的にグローバル変数化。
・少量のパターンにマッチさせるときはindex()、大量のパターンにマッチさせるときは正規表現をそれぞれ使う。ただし、大量すぎるとCPUキャッシュからあふれるようでかえって遅くなる。ものには限度がある。
例)
少量の場合

if( index( $_, '文字列1' ) >= 0 || index( $_, '文字列2' ) >= 0 ) {

大量の場合

if( /文字列1|文字列2|文字列3|...|文字列n/ ) {

・ウィキペディアで意味を持つ特定の英文字列(Categoryとか)を検出する必要があるんだけど、大文字小文字の揺らぎが許容されている。事前にケースを統一しておくことで、検出の正規表現にiオプションをつけなくて済むようにする。
・リンク候補を発見するため、本文に対して全記事名(150万件ある)をマッチングしていた(本文も150万件あるので、150万2回のマッチング)のを、本文を形態素解析して単語に分解し、単語の記事名が存在するかという処理方法に変えた。
・リンク先が曖昧さ回避を検出するため、本文に対して全曖昧さ回避記事名(5万件くらい)をマッチングしていた(本文150万件なので150万×5万回マッチング)のを、本文からリンクを抽出して曖昧さ回避リストに存在するかという処理方法に変えた。
・形態素解析(MeCab)では、最初はparseToNode()で先頭ノードを取得しループを回してノードを個別に取り出して処理していたが、parse()で分かち書きした結果を一括して受け取るようにした。


あおやぎのさいと2.0 新人うぃきめでぃあん日記