[ruby-core:27596] Re: better GC?

On Thu, Jan 14, 2010 at 15:06, Roger Pack <[e-mail]> wrote:
> that might be a more sane way of trying it out.
> That being said, typically GC only uses 10% of a ruby's time (I
> think), so it's not a super high performance hit currently.

I'm not sure what kinds of app code you've been running but I see
somewhere between 20% and 60% spent in memory management. This
includes well tuned code which avoids garbage when possible. Keep in
mind that you can't simple run a benchmark with no real heap. You'll
have to artificially add 60MB to 200MB of objects depending on what
your target runtime footprint will be.

> I've also been working on some "native type" wrappers [1] whose goal
> is basically to reduce the amount of memory Ruby has to traverse in
> order to do its mark and sweep.
>
> ex:
> a = GoogleHashSparseIntToInt.new
>
> a[3] = 4 # it saves these away as native C ints, so ruby's GC
> basically ignores all members.
>
> I'd be happy to add more functionality [like native {saved away}
> strings] or a wrapper to sets/priority queues/std::vector if anybody
> would find it useful just let me know.
>
> -r
> [1] http://github.com/rdp/google_hash

These sorts of libraries would be excellent to start publicizing. I'd
also be interested in doing some smarter implementations for hashes
along the lines of Lua's tables. Lua's ropes are also worth looking at
since there is a lot of string concat heavy code out there.

Io (iolanguage.com) for example, makes heavy use of unboxed type
collections to allow fast vector operations.

Brian.