On 8/17/06, Bill Kelly <billk / cts.com> wrote:
> From: "Francis Cianfrocca" <garbagecat10 / gmail.com>
> >
> > This is a perfect example of what I've noticed many times: Ruby's
> > performance is perfectly fast and acceptable until the working set gets a
> > certain (not terribly large) size, then it falls off a cliff. GC perhaps has
> > something to do with it, but I suspect that's only a small part of the
> > problem.
>
> Can anyone speculate as to what other subsystems or facets of Ruby's
> architecture, besides GC, might possibly cause this?
>

Total, rank speculation here, but I don't suspect GC because I
consistently see this kind of problem even when a lot of objects are
being created and not many are becoming garbage. My wild
unsubstantiated guess is that Ruby creates data structures in memory
that are not designed to maximize processor- and L2- cache
utilization. Perhaps data objects overflow cache lines, or they are
heavily pointer-driven (requiring more memory-bus cycles than is
optimal), or they exhibit poor locality of reference.