[Namazu-devel-ja 775] Re: File::MMagic::checktype_data

Yukio USUDA m6694ha392t @ asahi-net.or.jp
2005年 12月 15日 (木) 07:37:42 JST


臼田です

Tadamasa Teranishi wrote:
> > 
> > 試しにパターンが未定義ならsortでパターンを作って、定義済みなら
> > それを使うといったものに変えて測定してみてはどうでしょう。
> > それで速いようなら、addSpecials 時にsortしてパターンを更新するという
> > のを追加すれば良いでしょう。
> 
> 単純に sort の部分をコメントアウトしない修正版と修正前で比較しても
> 簡単に判断できるかもしれません。
> 

> どうやら m/(aa|bb|cc)/mg; の際、文字列の短いものからマッチング
> した方が速いようです。そのためsortしているようです。
> # しかし、そのためだけにsortしたのでは、sortのコスト分不利なんでは??
> 
my $token = '(' . (join '|', sort {length($a) <=> length($b)} @{$self->{SPECIALS}->{$type}}) . ')';
を
my $token = '(' . (join '|', @{$self->{SPECIALS}->{$type}}) . ')';
としても数%の違いしかありませんでした
ソートのコストとマッチングの高速化がつりあっているのか
どちらもそれほど大きく影響がないということかは確かめていません。
また、以前寺西さんが試した際に addSpecials 時に sort 結果を作成して
おいても数%の差しかなかったということから '|' による選択パターンが
重い処理なのだと思います。

> sortしようが、しまいが結果に差はなく、$val{$type} にパターンのうち、
> 最初にマッチングした次の位置が入ります。(それもパターンが長いとその分
> 後ろになるから、何か変)
> その後、位置情報でソートしてもっとも先頭に近い$typeが選ばれるようです。
> 
これも最初にマッチングした位置であれば
m/(aa|bb|cc)/m;
で良いと思えますが、gをとると make test に失敗しますし、
g をとっても数%しか速度が変わりませんでした。

元になったとされる file.kulp を見るとマッチしたら即確定となっている
ので判定条件については File::MMagic オリジナルの考え方のようです
http://ppt.perl.org/commands/file/file.kulp

	    my ($type,$token);
	    foreach $type (keys %SPECIALS) {
		foreach $token (@{$SPECIALS{$type}}) {
		    # we could do \b word boundaries if the end chars in
		    # $token were always \w, but they're not.  this is
		    # crude guessing anyway.
		    if ($data =~ /\Q$token\E/m) {
			$desc .= " $type";
			goto ALLDONE;
		    }
		}
	    }
	    
	  ALLDONE:
	    $desc .= " text";

> できるだけファイルの先頭の情報で判断できるものを優先するということ
> でしょうか。
> テキストの判定用のようですし、先頭のヘッダ情報で判定しないと、
> 本文中のテキストで判断してはまずいからかな???
> 
File::MMagic::checktype_data はテキスト判定用です。
ヘッダで判定するためには magic で判定する別ルーチンがあります。

臼田幸生




Namazu-devel-ja メーリングリストの案内