On 5/22/02 4:07 PM, "Art Taylor" <ataylor / fortpoint.com> wrote:

> Is there a particular kind or kinds of object being created in huge numbers?
> Can you pool those and reuse them rather than throwing them away?
> 
> -a.

This is the optimisation that has had the largest impact on programs I've
written in Eiffel, Java, and Smalltalk. These all have much fancier GC
systems that Ruby 1.6 and it still makes a big difference.

This is a pretty complicated problem. I've found it nearly impossible to
figure out what's going on in Ruby (there appear to be no memory profiling
tools available). Remember that the GC timing is mostly dependent on *live*
objects (I have not looked at Ruby, but some mark and sweep algorithms
compact memory in a way that is dependent on the size of the garbage). If it
was inexpensive to make an object then short-lived objects would be
inexpensive. Unfortunately, it costs you to create an object. Avoid doing
this (this is the advice Art gives). However, don't make more than you have
to. 

There is a problem that I have not worked out in Ruby -- if anyone else has
I'd really like to hear about it. Strings don't seem to have the necessary
API to allow them to be used as buffers. Conversion to/from arrays/strings
using pack/unpack is, in my opinion, too slow to be useful. Some people on
this list will be familiar with this issue in Java and with Java's String
and StringBuffer classes.

If you are using a lot of strings, you might want to take a look at this.

The timing you showed is interesting. You've got a pattern showing there.
Are you certain you aren't doing something different in the frames with the
long times on GC or immediately preceding those frames? Is the pattern
reproducible? always the same frames? Is there any other way you can predict
which frame will have the long GC? If you do then you can use the profiler
that is part of the AspectR package. This profiler can be controlled
programmatically. I've found this tool to be particularly useful. (But it
won't profile the GC).

Cheers,
Bob

Cheers,
Bob