in reply to Possible Memory Usage Issues

Now should perl be using 100 megs?

That's a bit hard to say without seeing a bit more of your code, including all of the "constants" that you're using as array indexes. If any one of those constants is a large number, you're going to be wasting lots of space in each Node and Leaf.

You could do away with $cont::getType entirely. You needn't hang on to "Node" or "Leaf" in each object. Instead, use ref() to check which type of thing you're looking at, or add an isLeaf member function to each object, returning 0 or 1 as appropriate.

Also, rather than hanging an anonymous array off of [$node::leaves], you could save a bit of space by keeping a separate [$node::left] and [$node::right]. The overhead for a slot within an array is lower than the overhead for an array, even if empty.

Replies are listed 'Best First'.
Re: Re: Possible Memory Usage Issues
by abitkin (Monk) on Aug 07, 2002 at 13:50 UTC
    Yes you're right, there's a lot of code to go with this, about 1400 lines.

    The reason I'm using an array, is based on command line options I'm passing in, I'm creating either a hex tree or a binary tree. I'm doing this becuase I'm using perl to get stats on the tree (as in the number of bits per prefix and such) for a piece of hardware we are putting a similar data structure in. This is basically our model, for the limiting case.

    Now as you may imagine, with this comes the idea that processing it takes a while. I've gotten it down to about 13 minutes on a dataset of 90,000+ records, using recursive calls and storing more data in nodes. If I were to add an isLeaf member function, I would have the cpu overhead of a function call every time I wanted to use that. I may switch it to 1/0, but doesn't that get rounded up to a 64-bit integer?

    I'm not seeing much space saved there.

    Thanks for the reply.
      If I were to add an isLeaf member function, I would have the cpu overhead of a function call every time I wanted to use that. I may switch it to 1/0, but doesn't that get rounded up to a 64-bit integer?

      You have a simple space/time tradeoff to make, and you've indicated that the problem is space. If the overhead isn't significant for a slot in the object to hold a boolean to indicate whether the object is a leaf, then do it. But if you're still tight on space, trade that boolean for a function call. Sure, a function call takes "more CPU", but do you know whether that additional time is significant (or even measurable)? I'll bet that the overhead of

      package Node; sub isLeaf { 0 } package Leaf; isLeaf { 1 }
      is barely measurable, and may be more than canceled out by not having to grow (at setup time) or access (at use time)the anonymous arrays that underly your objects.

        This seems to have helped some, but I was thinking that I may be able to side step the more cpu vs more ram issue by using inline c.

        However, I cannot seem to find a good ref for inline c, such as what happens to refs; or I could stop storing so much if my recursive calls ran fairly quickly, but when I pass my class to c++, does it keep the same methods, ect.