[#39845] Re: [ruby-cvs:33238] Ruby:r26022 (trunk): * marshal.c (w_object): dump instance variables when using — Tanaka Akira <akr@...>
2009/12/5 <[email protected]>:
3 messages
2009/12/06
[#39846] [Bug #2447] reduce GC pressure by symbol table without String instance — Yusuke Endoh <redmine@...>
Bug #2447: reduce GC pressure by symbol table without String instance
5 messages
2009/12/06
[#39847] stable find.rb — Tanaka Akira <akr@...>
44OH44Kj44Os44Kv44OI44Oq44KS5YaN5biw55qE44Gr44Gf44Gp44Gj44Gf57WQ5p6c44KS5q+U
5 messages
2009/12/06
[#39851] Time.now + str と #to_r — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
9 messages
2009/12/07
[#39852] Re: Time.now + str と #to_r
— "NARUSE, Yui" <naruse@...>
2009/12/07
成瀬です。
[#39855] [RubySpec #2460] RubySpecでFiberのSpecがおちる — 三村 益隆 <redmine@...>
RubySpec #2460: RubySpecでFiberのSpecがおちる
4 messages
2009/12/08
[#39863] [Feature #2471] want to choose a GC algorithm — _ wanabe <redmine@...>
Feature #2471: want to choose a GC algorithm
8 messages
2009/12/09
[#39874] faster Enumerator#each by rb_block_call with current block — Yusuke ENDOH <mame@...>
遠藤です。
7 messages
2009/12/13
[#39894] Re: faster Enumerator#each by rb_block_call with current block
— Yukihiro Matsumoto <matz@...>
2009/12/19
まつもと ゆきひろです
[#39897] Re: faster Enumerator#each by rb_block_call with current block
— Yusuke ENDOH <mame@...>
2009/12/20
遠藤です。
[#39912] [Bug #2522] Segmentation Fault is occurred on r26158 by running rubyspec — Kenta Murata <redmine@...>
Bug #2522: Segmentation Fault is occurred on r26158 by running rubyspec
4 messages
2009/12/23
[ruby-dev:39870] Re: [Feature #2471] want to choose a GC algorithm
From:
Narihiro Nakamura <authornari@...>
Date:
2009-12-11 00:25:27 UTC
List:
ruby-dev #39870
nari です。 2009年12月11日1:14 Yukihiro Matsumoto <[email protected]>: > まつもと ゆきひろです > > In message "Re: [ruby-dev:39867] Re: [Feature #2471] want to choose a GC algorithm" > on Fri, 11 Dec 2009 00:02:42 +0900, Narihiro Nakamura <[email protected]> writes: > > |ただ、GC自体の改善(高速化等)という観点で見ると、今までのCRubyのGCはそ > |れほど大きな改善はなされていないので、特にこのパッチが入ることによって、 > |さらに改善が遅くなるということもないのではないかと思います。 > |逆にLazySweepが上手く育ってくれれば、デフォルトのGCに取って代わるという > |のも面白いかもしれません。 > > っていうか、LazySweepって「取って代わる」ような大きなアルゴリ > ズムの変更ではないと思います。あまり大きなトレードオフもなさ > そうなので、ちゃんとバグが取れたならいつも有効にしていてもよ > いような。 > > そういう意味では、LazySweepがon/offできることのメリットが不明 > なので、このパッチには賛成しません。これがcopy-on-write > friendly GCとかmostly-copying GCのような性能特性が大きく変わ > りそうなものなら、切り替えに意味があるかもしれません。 > なるほど。確かにそうですね。 LazySweepのパッチはバグが取れていたと思うので、trunkに合わせた ものを作って、再度MLに投稿します。 -- Narihiro Nakamura (nari)