« Mac OS Xを10.6.6にアップデート | トップページ | [05]一里野温泉スキー場 - 出遅れパウダー »

2011年1月 8日 (土)

igo-rubyの性能

Rubyこの辺で作った形態素解析エンジンigo-ruby

あまりにも大きいドキュメントを解析するのは時間がかかるだろうと予想できるけど、どのくらいの粒度のドキュメントを解析すると実用的なのか、計測してみました。

一応、この辺で問題なく動いているんですけど、こういうのをそれなりに測定して、数字を知っておくと、それなりに有効だったりするわけです。

方針

計測用のドキュメントを用意するのは面倒なので、Twitterの自分のアカウントのステータスを200個取得して、1ステータスずつ200回解析する場合と、200ステータスを結合した上で1回解析する場合を比較してみる。

解析するドキュメントサイズは同じなんだけど、細かく解析した方がいいのか、まとめて解析した方がいいのか、差がある場合、どのくらい差が出るのかを知りたい。

テストコード


使用するigo-rubyの機能は「分かち書き」にした。(内部で形態素解析を使用しているので特に問題にはならない)
Twitterからのステータスの取得コスト、igo-rubyのインスタンスの生成コスト、ステータスの結合コストは性能測定の対象外とした。
1ステータスずつ200回解析する方(eachの方)は、分かち書きの結果を配列に追加していくコストも含んでいるので若干不利なんだけど、そのつもりで結果を見ればいいかと。

結果

$ ruby igo-ruby-test.rb 
      user     system      total        real
each:  2.010000   0.040000   2.050000 (  2.046613)
each: result size = 5721
join: 27.140000   0.670000  27.810000 ( 27.816586)
join: result size = 5699

1ステータスずつ200回解析する方が、200ステータスを結合したドキュメントを1回解析するより、一桁速い。
その差、14倍弱。

分かち書きの結果数(result size)に差があるけど、まぁ、単純に結合ししているので合わないかもしんない。ここでは、両方とも同程度の形態素に分かれていることが示せれば良い、とする。

しかし、こんなに違うのか…。

逆に言うと、1つのドキュメントを200個に分解し、それぞれを解析した方が、14倍程度速いとも言える。まさにMapReduceの考え方そのもの。(*)

* この計測では200回の解析をシーケンシャルに行なっているので、それらを分散処理するMapReduceとは、正確には異なります。ここでは、解析単位を細かくした方が性能が出るという意味でMapReduceを引き合いに出しました。

結論

igo-rubyを使う場合は、最大140文字くらいのドキュメント毎に解析処理を繰り返せば、それなりに実用的な性能が出ますヨ。

|

« Mac OS Xを10.6.6にアップデート | トップページ | [05]一里野温泉スキー場 - 出遅れパウダー »

Ruby」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/16742/50523398

この記事へのトラックバック一覧です: igo-rubyの性能:

« Mac OS Xを10.6.6にアップデート | トップページ | [05]一里野温泉スキー場 - 出遅れパウダー »