Re: Retrieving the actual memory size of a pfNode

New Message Reply Date view Thread view Subject view Author view

From: Michael J. Lewis (mlewis++at++evl.uic.edu)
Date: 07/20/2001 14:00:13


Hello Yair

My purpose of measuring the memory consumption of a sub tree, was
to find out memory each node would be using and to know how much
more free shared space I would have if I deleted the node.

I also wanted to know this for mainly statistical information.
i.e loading a model under a sub tree takes up x amount of memory.
Because if I am correct to just look at the size of a .pfb or .iv
model doesnt not neccesarily tell you how much memory that file would take
up when loaded via pfLoadFile in performer.

Thanks

Mike
  

On Fri, 20 Jul 2001, Yair Kurzion wrote:

> Hi Michael !
>
> Comments:
>
> o When you create nodes, Performer may (depending on your multiprocessing mode)
> create clones of these nodes for multi-buffering purposes. For each forked
> CULL or for ISECT, performer makes a clone of each internal scene graph node.
> geosets and other leaf nodes are not cloned.
>
> o Some nodes have internal structures (e.g. lists) that they allocate when you
> create them. getSize only reports the size of the class itself (members), not
> external allocated memory.
>
> o Each node is registered in Performer internal structures. When registering
> a new node, these structure may have grow. Measuring the total amount of
> memory used includes this unpredictable (by an application) growth.
>
> o pfMemory::getSize works in all modes (not DEBUG only).
> pfMemory::getArenaBytesUsed only works in DEBUG libraries for performance
> reasons. It is meant for memory-leak debugging.
>
> Could you please explain what you are trying to achieve by measuring the memory
> consumption of a sub-tree in runtime ?
>
> Thanks,
> -yair
>
>
> > I have a pfNode that was created with the pfdLoadFile using an iv or pfb
> > model
> >
> > My problem is trying to get the actual memory size of the whole tree
> > under the pfNode. My
> > subroutine listed underneath recursively gets the size of all the
> > pfGeosets and sums up all the
> > sizes of the geosets. However my total size result is no where near the
> > actual memory of the
> > loaded pfNode. From doing an amallinfo before and after loading the
> > pfNode I get a memory size
> > much higher than when I recursively get the sizes. But doing amallinfo
> > before or after a load can
> > be unreliable especially if an object has been deleted before.
> >
> > Any suggestions in how to consistently record the true memory size of a
> > loaded pfNode object. Should
> > I add anything more to my function below.
> >
> > void getMemSize(pfNode *node)
> > {
> > int i;
> > if (node->isOfType(pfGeode::getClassType()))
> > {
> > pfGeode *geode = (pfGeode *)node;
> > for (i=0; i < geode->getNumGSets(); i++)
> > {
> > pfGeoSet *gset = geode->getGSet(i);
> > int geoSetSize = gset->getSize();
> > totalSize = totalSize + geoSetSize; // totalSize
> > is a global variable
> > }
> > }
> > else if (node->isOfType(pfGroup::getClassType()))
> > {
> > pfGroup *group = (pfGroup *)node;
> > for (i=0; i < group->getNumChildren(); i++)
> > {
> > getMemSize(group->getChild(i));
> > }
> > }
> >
> > }
> >
> > Also I notices that the getSize() function only works in the 2.4 using
> > the debug libraries. Is there any intent
> > to make this a main stream call.
> >
> >
> > Thanks
> >
> > Michael J. Lewis
> > mlewis++at++evl.uic.edu
> >
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Open Development Project: http://oss.sgi.com/projects/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> >
>
>
> --
> \_________ \_____ \__ \__ \_____ Yair Kurzion
> \_________ \_____ \__ \__ \_____ yair++at++sgi.com
> \__ \__ \____\__ \__ http://reality.sgi.com/yair
> \__ \__ \__ Work: (650) 933-6502
> \__ \__ \__ Home: (408) 226-9771
> \__ \__ \__
>


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Fri Jul 20 2001 - 14:00:49 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.