morit****@razil*****
morit****@razil*****
2009年 5月 12日 (火) 16:39:53 JST
森です。 hookがなくて、GRN_COLUMN_VAR_SIZEでないなら grn_obj_get_valueしないで上書きするようにしました〜。 手元だとruby hashより1割ぐらい速く動いています。 >>> morit****@razil***** さんは書きました： > > 森です。 > > なるほどー。比較的長めの文書データをセットして、 > フックで転置索引を更新するようなケースを主に想定して書いてたので、 > その辺の考慮が浅かったかも知れないです。 > > 検討してみます。 > > >>> Kouhei Sutou さんは書きました： > > 須藤です。 > > > > grn_obj_set_value()が少しオーバーヘッドが大きい感じがするの > > ですが、毎回oldvalueを取得するのではなくて、必要な時だけ > > oldvalueを取得するようにしてはどうでしょうか？ > > > > 例えば、GRN_HOOK_SETが設定されている時だけ、とかです。 > > > > > > 試しに、ハッシュのことだけを考えてみると、 > > 現在のgrn_obj_set_value()は > > > > (1-1) grn_obj_get_value()で現在値を取得 > > （1回検索） > > (1-2) 設定しようとしている値と比較して同じだったらreturn > > (1-3) フックがあったら実行 > > (1-4) 値を設定 > > （1回検索） > > > > という感じになっています。 > > > > もし、フックがない場合は、 > > > > (2-1) grn_obj_get_value()で現在値を取得 > > （1回検索） > > (2-2) 設定しようとしている値と比較して同じだったらreturn > > (2-3) 値を設定 > > （1回検索） > > > > となります。 > > > > で、このとき、(2-2)で(-23)の処理を枝刈りしてやるよりも、「同 > > じ値でも上書き」しちゃった方が速い気がします。 > > > > (3-1) 毎回値を設定 > > （1回検索） > > > > ソースを見ると、ハッシュで値を設定する時は、値を取得してそこ > > にmemcpy()しているので、(2-3)の処理を枝刈りするよりも(2-3)だ > > けやっちゃえば速いんじゃないかなぁ、という感じです。 > > > > > > 試しに、↑のようにgroongaを変更して、手元でRubyバインディング > > のベンチマークを走らせてみると、RubyのHashと同じくらいまで速 > > くなりました。 > > > > > > まだアイディアだけで、網羅的な計測とか問題があるケースとかを > > 検討したりしていないのですが、もしよかったら少し考慮してもら > > えると嬉しいです。 > > > > _______________________________________________ > > groonga-dev mailing list > > groon****@lists***** > > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev > > > -- > morita > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev > -- morita
