Feature #2447
Updated by ko1 (Koichi Sasada) almost 12 years ago
=begin 遠藤です。 現在のシンボルテーブルは、シンボルごとに String のインスタンスを 割り当ててシンボル名を管理しますが、そのせいで GC の効率が落ちて いると思います。 String ではなく ALLOC で直接確保した領域で管理するパッチを書きま した。極端な例ではこのくらい早くなります。 # パッチ前 $ time ./ruby.org -e '10000.times { GC.start }; p ObjectSpace.count_objects[:T_STRING]' 1778 real 0m3.766s user 0m3.764s sys 0m0.004s # パッチ後 $ time ./ruby.new -e '10000.times { GC.start }; p ObjectSpace.count_objects[:T_STRING]' 433 real 0m2.880s user 0m2.876s sys 0m0.004s benchmark 結果は最後にあります。多くのものはほぼ変わらないか速く なっていると思います。 so_meteor_contest は有意に速度低下しますが (再現性あり) 、理由は よくわかりません。vm3_thread_mutex は実行する度に実行時間が大きく 変わっていた (3 秒以下から 30 秒超) ので、参考になりませんでした。 どなたか追試してくださると助かります。私の環境で make test-all は 通っています。 1.89s (2.57%): vm2_eval 73.65->71.76 1.88s (2.44%): so_fannkuch 77.14->75.25 1.86s (8.08%): so_partial_sums 23.04->21.18 1.73s (7.20%): so_mandelbrot 23.98->22.26 1.43s (8.68%): so_spectralnorm 16.43->15.00 1.02s (6.19%): so_nbody 16.49->15.47 0.99s (1.13%): app_pentomino 87.50->86.51 0.82s (6.67%): vm1_block 12.23->11.41 0.76s (5.28%): so_nsieve_bits 14.37->13.61 0.51s (15.68%): vm3_gc 3.25->2.74 0.34s (3.16%): so_fasta 10.69->10.35 0.23s (5.13%): so_exception 4.52->4.29 0.22s (3.01%): loop_for 7.45->7.22 0.19s (9.06%): app_raise 2.10->1.91 0.18s (4.67%): so_object 3.88->3.70 0.12s (1.77%): loop_times 6.54->6.42 0.11s (8.49%): so_random 1.31->1.20 0.09s (2.44%): app_uri 3.88->3.78 0.09s (1.07%): vm1_simplereturn 8.35->8.26 0.07s (4.13%): app_strconcat 1.64->1.57 0.06s (0.80%): vm2_mutex 7.33->7.27 0.06s (2.94%): app_erb 1.95->1.89 0.05s (0.59%): vm2_method 8.94->8.89 0.04s (1.04%): vm2_array 3.63->3.59 0.04s (0.97%): vm1_rescue 3.80->3.76 0.03s (0.56%): so_nested_loop 5.88->5.85 0.03s (0.75%): loop_generator 3.83->3.80 0.03s (0.51%): so_pidigits 5.38->5.35 0.03s (2.87%): io_file_read 0.95->0.93 0.03s (0.74%): vm2_proc 3.51->3.48 0.02s (0.65%): vm1_ensure 3.82->3.79 0.02s (1.45%): vm2_poly_method_ov 1.64->1.61 0.02s (0.74%): vm2_zsuper 2.88->2.86 0.02s (2.50%): app_mandelbrot 0.83->0.80 0.02s (0.46%): app_tak 4.36->4.34 0.02s (1.34%): vm2_case 1.24->1.23 0.01s (1.04%): io_file_create 1.18->1.17 0.01s (0.43%): so_matrix 2.11->2.10 0.01s (0.18%): so_ackermann 3.62->3.62 0.01s (0.19%): app_fib 3.21->3.21 0.01s (1.47%): so_sieve 0.41->0.40 0.00s (0.06%): vm1_ivar 6.23->6.22 0.00s (0.03%): so_concatenate 1.91->1.91 0.00s (0.05%): app_factorial 0.66->0.66 0.00s (0.00%): vm1_neq 6.22->6.22 -0.00s (-0.03%): vm2_send 2.02->2.02 -0.00s (-0.41%): app_answer 0.24->0.25 -0.00s (-1.53%): so_reverse_complement 0.09->0.09 -0.00s (-1.96%): so_k_nucleotide 0.07->0.07 -0.00s (-0.38%): io_file_write 0.44->0.44 -0.00s (-0.11%): loop_whileloop 3.38->3.39 -0.00s (-0.13%): app_tarai 3.51->3.51 -0.01s (-0.64%): so_count_words 1.09->1.10 -0.01s (-0.68%): so_lists 1.68->1.69 -0.02s (-2.50%): loop_whileloop2 0.67->0.68 -0.02s (-1.04%): vm2_unif1 1.76->1.78 -0.02s (-1.12%): so_binary_trees 1.81->1.83 -0.03s (-1.10%): vm2_super 2.75->2.78 -0.03s (-0.56%): vm1_const 5.80->5.83 -0.05s (-0.70%): vm2_regexp 6.55->6.59 -0.05s (-0.51%): vm3_thread_create_join 10.49->10.55 -0.06s (-1.18%): vm1_swap 5.18->5.24 -0.11s (-2.21%): vm1_not 4.91->5.02 -0.14s (-1.19%): vm2_poly_method 11.83->11.97 -0.14s (-2.11%): vm1_length 6.64->6.78 -0.15s (-2.33%): vm1_ivar_set 6.57->6.72 -0.18s (-2.42%): so_array 7.40->7.58 -0.31s (-2.23%): so_nsieve 13.79->14.10 -2.22s (-8.38%): so_meteor_contest 26.50->28.72 -26.20s (-177.28%): vm3_thread_mutex 14.78->40.99 -- Yusuke Endoh <mame@tsg.ne.jp> =end