Re: Object/Memory Management

On 2/25/02 6:13 AM, "Chris Gehlker" <[e-mail]> wrote:

>> Automatic memory management has no inherent problems outside of hard
>> real time or extremely memory-constrained environments, as far as I
>> know.  For a sufficiently sophisticated GC algorithm that matches the
>> language or environment, automatic memory management can do as well or
>> better than manual memory management.  One can't judge all GC by Java's
>> performance.
>> 
>> Having said that, GC can get tricky to get right, and even trickier to
>> optimize.  I don't know the specifics of Ruby's GC, apart from it using
>> mark-sweep with no copying or compaction.  Maybe others can tell of
>> specific weaknesses or pathological behaviors they've seen; I haven't
>> done any heavy lifting in Ruby yet.
> 
> Nor I. I'm inferring, perhaps over-inferring, from remarks on the Ruby Cocoa
> page that Ruby Cocoa is more suitable for prototyping than for producing
> commercial quality desktop apps. I took this to be more of a comment on the
> nature of Ruby than on any implementation details of the Cocoa interface.

My take is this is more due to the current development stage of RubyCocoa
than to the nature of Ruby. I can say that a RubyCocoa app feels slower for
many tasks than an equivalent app written in JavaCocoa, but I haven't done
any objective measurements. There are some obvious runtime improvements that
both the Ruby and RubyCocoa implementations could use in Mac OS X, like
scatter loading and adoption of the two-level namespace feature, but I don't
know how much difference these will make for a typical Ruby program.

Java 2 has two interesting things that Ruby doesn't:

- a JIT compiler
- a generational garbage collector (IIRC), which might be more efficient for
Ruby than the current mark-sweep GC

Chris