Have a look at malloc_increase and malloc_limit in gc.c

It means Ruby will GC whenever you have allocated more than XXX since the last GC.

XXX starts at 8mb, but changes according to:

(live is the number of live objects, freed is the number we will be getting rid of, I think.)

Wunderbar! This is the missing link I have been waiting for for 2 years now. Thanks so much Why, you really did the right thing, at least this time.

This provokes 2 questions from me:

1) If there are all these heaps which Ruby uses for holding objects in groups of 10_000, then would it be particularly difficult to have Heap as a native type in Ruby?

2) I’m wondering to what extent allocation comes into speed of deletions from arrays/hashes. I have on a couple of occasions reasoned that database access, or complicated maths, would be faster if I cached the results. However, using a bounded Array of Arrays and assoc(), or using a hash with a limited number of keys, it has been slower than not caching at all. Are there well known ways of doing this effectively that I have missed?

The Lua book has an interesting take on building long strings out of small ones, which I think only applies when strings are immutable, but it’s interesting nonetheless: 11.6 String buffers which uses a sort of Tower of Hanoi—you can’t put a long string on the end of a shorter one.

You could try using Symbols which are faster to compare and look up in Hashes than regular Strings. You can convert a String to a Symbol via String#to_sym and there is also a Symbol literal notation :foo or :”foo”—the latter also allows for interpolation.

timsuth: if people want me to go into that, I will. My point was that once you rise about eight megs, the allocation limits will change. “Ruby will begin to watch your allocation needs and resize the limit accordingly.” I don’t really understand the logic behind the malloc_increase computation, maybe someone can clue me in on it. Specifically, why is live / freed important?

You should really go into the fact that allocating a continuous region is a lot more hard on the memory manager than many small regions.

hgs: you can certainly put a long string on the end of a shorter one. The algorithm makes sure that they’ll stack properly.

I’m again going to say that the rope data structure would be really great to have in Ruby, as it encapsulates the behavior of multiple concatenations efficiently.

hgs: What would you do with a native Heap object if you had one?

flgr: Symbols are also less expensive memory-wise: if the same string values get used multiple times, each unique value is only stored in the underlying table once.

There are disadvantages, though.

One thing to be aware of is that (as far as I know), the strings in the underlying table underlying never get freed. So it’s probably best not to use Symbols for cases where you expect to be encountering a whole lot of unique strings—you’d just grow the table really fast.

The other thing is that Symbols can’t be used to represent an empty string.

_why: It’s really the whole live / ( live + freed ) ratio that’s relevent—it reflects the percentage of objects which survived the just-completed GC pass.

Multiplying by it reduces the magnitude of malloc_limit changes during periods of massive freeing (when a smaller percentage of objects have survived).

This is probably motivated by situations like those where a bunch of objects get reaped in response to (what might be) the first of a slew of new allocations. Dropping the limit drastically only to have to increase it again could have performance consequences. The ratio introduces a little bit of hysteresis.

Determining whether that is actually helpful is probably the purview of benchmarkers.

Good points, MenTaL. The point about symbols is worth educating. This is exactly what I’m looking for: how we’re unknowingly affecting memory, the decision we’re making by using certain approaches. We just don’t talk about it because it’s probably too timely—could change in the future.

My bet is that it won’t for some time. And, when it does, we still need to know what’s going on.

Okay, I buy the explanation of live / (live + freed) as a simple hysteresis. Now, how does this affect the common user? I think I’m covered by recommending that we free a big pile of objects at once rather than trickling them out.

_why: Probably yeah.

Incidentally, there’s another bit you might want to cover under category #2—closures.

A closure will hang on to all the variables belonging to the scope in which it is created, including self and all of its instance variables. This is true whether or not any of those variables are actually used within the closure.

e.g.

  require 'weakref'

  def bramf(zoogma)
    lambda {}
  end

  foo = Object::new
  bar = WeakRef::new(foo)

  baz = bramf(zoogma)

  foo = nil
 GC.start
  p bar.weakref_alive? # => true

  baz = nil
  GC.start
  p bar.weakref_alive? # => false

When hanging onto parameters or local variables would create problems, two options are:

1. set such variables to nil before taking the closure:

def bramf(zoogma)
  zoogma = nil
  lambda {}
end

<code>
def bramf(zoogma)
  bramf_closure
end
def bramf_closure
  lambda {}
end
</code>