On 18 Jun., 08:26, David Masover <ni... / slaphack.com> wrote:
> On Tuesday 17 June 2008 10:53:56 Robert Klemme wrote:
>
> > Typically you would rather be interested in a particular part of the
> > object graph that is reachable from an instance - and here it becomes
> > difficult, because any object can have any number of references and
> > can be referred to any number of times.  Where then do you count the
> > memory?  Or do you count it multiple times? etc.
>
> I think this is analagous to a filesystem structure. It is possible to do
> roughly all of the above with tools like ls and du

That's a good analogy for reasoning about this topic.  But there are
differences as well: file systems are typically mostly organized
hierarchically, i.e. there are just few links between different sub
trees of the complete tree.  This is why tools like "ls" and "du" are
useful in practice because you can be pretty sure, that only a
negligible portion of disk usage is counted more than once.  But the
topology of an object graph might look totally different, i.e. more
interconnected.

Then there are different types of links - soft links and hard links.
This gives file system utilities a means to ignore paths.  Usually
soft links are much more often used than hard links (in my personal
experience anyways) while hard links more closely resemble object
references in Ruby.

What are files in a file system would probably be Strings in Ruby
world (raw allocated sequences of bytes that are not used for
referencing).  All other objects rather behave like directories, i.e.
they have only references to other objects.

> But then, I've always been more for letting Ruby take as much RAM as it wants
> until I run out, and then start optimizing.

Which is an approach in the pragmatic spirit of Ruby. :-)

I just hacked together a toyed memory analyzer.  You can find it here
http://www.pastie.org/217131

Kind regards

robert