[#43857] Hashへの生成順は保障されないのか? — Hiroshi Kasamatsu <qqmn89yb9@...>

こんにちは、笠松と申します。

88 messages 2007/08/18
[#43858] Re: Hashへの生成順は保障されないのか? — Urabe Shyouhei <shyouhei@...> 2007/08/18

Hiroshi Kasamatsu wrote:

[#43862] Re: Hashへの生成順は保障されないのか? — Hiroshi Kasamatsu <qqmn89yb9@...> 2007/08/19

皆さん、早速のレスありがとうございます。

[#43863] Re: Hashへの生成順は保障されないのか? — Urabe Shyouhei <shyouhei@...> 2007/08/19

Hiroshi Kasamatsu wrote:

[#43870] Re: Hashへの生成順は保障されないのか? — Hiroshi Kasamatsu <qqmn89yb9@...> 2007/08/20

Urabeさん、笠松です。レスありがとうございます。

[#43872] Re: Hashへの生成順は保障されないのか? — Urabe Shyouhei <shyouhei@...> 2007/08/20

Hiroshi Kasamatsu wrote:

[#43873] Re: Hashへの生成順は保障されないのか? — cuzic <cuzic@...> 2007/08/20

cuzic です。

[#43874] Re: Hashへの生成順は保障されないのか? — Urabe Shyouhei <shyouhei@...> 2007/08/20

cuzic wrote:

[#43875] Re: Hashへの生成順は保障されないのか? — Tanaka Akira <akr@...> 2007/08/20

In article <46C9E7BB.4060100@ruby-lang.org>,

[#43876] Re: Hashへの生成順は保障されないのか? — Urabe Shyouhei <shyouhei@...> 2007/08/20

おお、田中さんを満足させる説明ってのは結構ハードル高そうだな。

[#43878] Re: Hashへの生成順は保障されないのか? — しん <dezawa@...> 2007/08/20

# 出遅れたので、レスすべきメールが判らなくなってしまったので、手近なのに

[#43879] Re: Hashへの生成順は保障されないのか? — Yukihiro Matsumoto <matz@...> 2007/08/20

まつもと ゆきひろです

[#43887] Re: Hashへの生成順は保障されないのか? — Nobuyoshi Nakada <nobu@...> 2007/08/21

なかだです。

[#43891] Re: Hashへの生成順は保障されないのか? — SASADA Koichi <ko1@...> 2007/08/21

 ささだです。

[#43892] Re: Hashへの生成順は保障されないのか? — Yukihiro Matsumoto <matz@...> 2007/08/21

まつもと ゆきひろです

[#43893] Re: Hashへの生成順は保障されないのか? — Nobuyoshi Nakada <nobu@...> 2007/08/21

なかだです。

[#43899] Re: Hashへの生成順は保障されないのか? — "Akinori MUSHA" <knu@...> 2007/08/21

At Tue, 21 Aug 2007 13:59:43 +0900,

[#43900] Re: Hashへの生成順は保障されないのか? — SASADA Koichi <ko1@...> 2007/08/21

 ささだです。

[#43906] Re: Hashへの生成順は保障されないのか? — "Akinori MUSHA" <knu@...> 2007/08/21

At Tue, 21 Aug 2007 19:29:11 +0900,

[#43921] Re: Hashへの生成順は保障されないのか? — Tanaka Akira <akr@...> 2007/08/22

In article <86sl6dgikh.knu@iDaemons.org>,

[#43926] Re: Hashへの生成順は保障されないのか? — Tanaka Akira <akr@...> 2007/08/23

In article <87zm0kaz60.fsf@fsij.org>,

[#43927] Re: Hashへの生成順は保障されないのか? — Yugui <yugui@...> 2007/08/24

Yuguiといいます。

[#43930] Re: Hashへの生成順は保障されないのか? — Yukihiro Matsumoto <matz@...> 2007/08/24

まつもと ゆきひろです

[ruby-list:43922] Re: Hashへの生成順は保障されないのか?

From: Tetsuo Sakaguchi <saka@...>
Date: 2007-08-22 12:06:00 UTC
List: ruby-list #43922
阪口です。

In message <20070821141439.GA92126%saka@slis.tsukuba.ac.jp> 2007-08-21T23:14+0900,
	Tetsuo Sakaguchi <saka@slis.tsukuba.ac.jp> wrote:
> PS. 時間がとれれば環境整えて自分でパッチを当ててみようかとも思いますが、、。

ちょっとためしたけど、単純に(ordered-hash抜きでは)適用できないので、

> このパッチ、rehashのメモリの割り当てが Calloc(=calloc) から、
> xrealloc に変更されていますね。

単純に Calloc -> xmalloc にしてみたもので、ベンチマークしてみました。
(diff は添付しておきます。エイやっと作ったので、ミスがあるかも。。)

見ればわかる通り、当たり前ですが全体として性能がそこそこ上がっています。
(clear が落ちているように見えるけど、この値だと測定誤差とか他負荷の
要因は無視できないし。。。もうちょっと長時間で計らないと。。)

ご参考まで。

個人的には、組み込みクラスは基本的な機能に絞っておいて、派生的な
機能を持たせる場合でも、速度や記憶使用量の増加はせいぜい数%程度までの
ものにしておいて欲しいと思いますが、、。
(awk の連想配列でも要素の追加順序は保存されませんし、、、。)


1.8.6-p36 のまま
                                              user     system      total        real
add to empty hash                         1.150000   0.020000   1.170000 (  1.177728)
add to hash with 100000 elements          1.950000   0.030000   1.980000 (  1.978130)
each_key with 200000 elements             0.100000   0.000000   0.100000 (  0.099460)
keys.sort_by.each, 200000 elements        2.350000   0.030000   2.380000 (  2.373399)
delete 100000 times, non-existing key     0.060000   0.000000   0.060000 (  0.062486)
delete 100000 times, existing keys        0.490000   0.000000   0.490000 (  0.487005)
include? 100000 times, non-existing key   0.060000   0.000000   0.060000 (  0.054519)
include? 100000 times, existing keys      0.400000   0.000000   0.400000 (  0.401355)
clear hash with 100000 elements           0.020000   0.000000   0.020000 (  0.022875)

rehash で、Calloc -> xmalloc したもの
                                              user     system      total        real
add to empty hash                         0.960000   0.010000   0.970000 (  0.978789)
add to hash with 100000 elements          1.680000   0.020000   1.700000 (  1.692938)
each_key with 200000 elements             0.080000   0.000000   0.080000 (  0.085035)
keys.sort_by.each, 200000 elements        1.610000   0.020000   1.630000 (  1.629927)
delete 100000 times, non-existing key     0.050000   0.000000   0.050000 (  0.047612)
delete 100000 times, existing keys        0.320000   0.000000   0.320000 (  0.326661)
include? 100000 times, non-existing key   0.040000   0.000000   0.040000 (  0.043253)
include? 100000 times, existing keys      0.380000   0.010000   0.390000 (  0.373585)
clear hash with 100000 elements           0.040000   0.000000   0.040000 (  0.047428)

--
阪口哲男@図書館情報メディア研究科.大学院.筑波大学
Tetsuo SAKAGUCHI.
Graduate School of Library, Information and Media Studies
University of Tsukuba, JAPAN.

Attachments (1)

st-diff (515 Bytes, text/plain)
--- ruby-1.8.6-p36-org/st.c	2007-02-13 08:01:19.000000000 +0900
+++ ruby-1.8.6-p36/st.c	2007-08-22 20:41:40.984776000 +0900
@@ -321,7 +321,9 @@
     unsigned int hash_val;
 
     new_num_bins = new_size(old_num_bins+1);
-    new_bins = (st_table_entry**)Calloc(new_num_bins, sizeof(st_table_entry*));
+    new_bins = (st_table_entry**)
+	    xmalloc(new_num_bins * sizeof(st_table_entry*));
+    for (i = 0; i < new_num_bins; i++) new_bins[i] = 0;
 
     for(i = 0; i < old_num_bins; i++) {
 	ptr = table->bins[i];

In This Thread