From: matz@... (Yukihiro Matsumoto)
Date: 2001-01-06T02:13:47+09:00
Subject: [ruby-talk:8696] Re: Interesting Language performance comparisons - Ruby, OCAML etc

Hi,

In message "[ruby-talk:8670] Re: Interesting Language performance comparisons - Ruby, OCAML etc"
    on 01/01/05, Josh Stern <jstern@foshay.citilink.com> writes:
|
|>Now, Ruby's speed isn't perfect. In particular, it is severely hampered 
|>by the current garbage collection overhead once you start getting
|>1,00's of objects on the heap, and that can slow up the "parse a file, 
|>process the objects" kind of application. The new generational GC
|>should help a lot there, and it will be interesting to see what effect 
|>that has on the string-based tests.
|
|Has there been any public discussion of a new GC strategy?  I'm
|not any kind of expert, but my understanding is that 'generational'
|generically refers to methods for amortizing GC usage over time 
|rather than to any algorithmic speedup in the overall time spent 
|doing GC.  The amortizing would help, say, the responsiveness of
|a user interface, but not a benchmark.
|
|One strategy that I suspect would help Ruby GC would be to
|treat class definitions, method definitions, and global
|objects differently than other garbage, since they are 
|expected to be long-lived.  Perhaps they should go on
|a different, compactified heap.

Why don't you try and see by yourself?

Generational GC patch is available at

 http://ruri.csys.ce.hiroshima-cu.ac.jp/~masato/download/gc-patch-1.6.2.diff

Note it's still experimental.

							matz.