Re: what is _pfCuller doing here? (2nd try)

New Message Reply Date view Thread view Subject view Author view

Alejandro Saez (cano++at++krusty.engr.sgi.com)
Thu, 13 Aug 1998 19:29:32 -0500

On Aug 13, 11:50am, Daniel Williams wrote:
> Subject: what is _pfCuller doing here? (2nd try)
> I sent this last Friday and haven't gotten any response
> from the Performer team so I'm trying again:
>
> My application manages hundreds to thousands of entities in my
> pfScene. Each entity is represented by a subclass from pfGroup that
> contains a geode with two geosets and a draw callback.
>
> I'm trying to understand the memory allocation behavior of my
> application and have discovered that a pool of arena memory is being
> accumulated at the following location:
>
> pfMemory::operator new(unsigned int,unsigned int,void*)
> [pfMemory.C:105]
> pfMemory::malloc(unsigned int) [pfMemory.C:480]
> _pfCuller::pf_getFuncs(void) [pfCuller.C:637]
> _pfCuller::pf_flushStackState(void) [pfCuller.C:426]
> _pfCuller::add(pfGeoSet*) [pfCuller.C:369]
> pfGeode::nb_cull(int,int,_pfCuller*) [pfGeode.C:269]
> pfGroup::nb_cull(int,int,_pfCuller*) [pfGroup.C:306]
> pfScene::nb_cull(int,int,_pfCuller*) [pfScene.C:293]
> _pfCuller::nb_cull(void) [pfCuller.C:208]
> beginDraw(int) [pfProcess.C:6293]
> pfDraw [pfProcess.C:6347]
> pfDWChannel::drawCallback(pfChannel*,void*)
> [pfDWChannel.c++:225]
> pfChannel::pf_callDrawFunc(void) [pfChannel.C:2194]
> doDraw(pfChannel*,pfPipe*,int*) [pfProcess.C:6200]
> appCullDraw(int) [pfProcess.C:3944]
> pfFrame [pfProcess.C:4400]
>
> The memory seems to be associated with pfChannel because usage doubles
> if I run in stereo.
>
This sort of makes sense, different channel, differet view parameters,
different culling..

> This memory is not freed when I delete the entities; instead, it seems
> to be reused for subsequent entities. It is allocated in binary
> exponential form:

This is the normal behaviour for malloc, the allocated memory is not really
freed to other processes after the free operation, it's just marked free for
future use within the same application. This won't be really freed after the
application is exited. I understand this is the normal UNIX way of doing it.
I don't know what _pfCuller does.. it's just that you sounded worried about
this being abnormal and just wanted to say it isn't

>
> 11296 bytes allocated in 2 blocks
> 22592 bytes allocated in 4 blocks
> 45184 bytes allocated in 8 blocks
> 90368 bytes allocated in 16 blocks
> 180736 bytes allocated in 32 blocks
> 361472 bytes allocated in 64 blocks
>
> This is worrying because if my calculations are correct, the memory
> used is (5648 bytes) * number-of-entities * number-of-channels; if I
> have 5000 entities on a 3-pipe stereo machine my usage is 161 MB for
> something I know nothing about.
>
> Can someone peer into the pfSourceCode and tell me what _pfCuller is
> doing in this case and how I might avoid it?
>
> Thanks,
> Dan
> --
> Daniel Williams, Systems & Scientific Software
> Voice: (215) 885-1573 Email: sass++at++acm.com
> Independent Consultant to: Sarnoff Corporation
> Voice: (609) 734-2153 Email: dwilliams++at++sarnoff.com
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Daniel Williams

-- 
------------------------------------------------------------------------
Alejandro Saez
Software Engineer
Silicon Chile S.A.
                                        Avda. Santa Maria 2560
E-mail: asaez++at++silicon.cl              	Providencia
Phone:  +56 (2) 203 3371 Ext. 107 		Santiago
Fax:    +56 (2) 203 3370                Chile
------------------------------------------------------------------------

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Thu Aug 13 1998 - 16:31:35 PDT

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