Angus Dorbie (dorbie++at++sgi.com)
Thu, 16 Sep 1999 14:36:56 -0700
This makes a massive difference to fragmentation. There have been other
posts on this. A couple of simple parameters seem to make most impact:
M_MXFAST set to something higher maybe 100 or more, note you need to do
this before pfInit so you need to initialize the memory arena first.
This also implies making M_NLBLKS a little larger.
M_MXCHK should be much larger but may slow malloc, this is an very
important change.
M_FREEHD is also important. In fact if you do these last two then the
first M_MXFAST change might not make a big difference and you don't have
to mess with your own memory initialization.
Cheers,Angus.
"Doug Chism (DAS)" wrote:
>
> I am working on an application that tessellates polygonal structures and
> deforms them in real time. Currently the biggest problem is that memory
> becomes fragmented very quickly. In fact, if I never free the memory I
> allocate, it runs approx 4/5 as long as when I free the memory after it
> is not being used. There are no memory leaks, as all the pfMalloc and
> pfDelete calls are in 1 function. The problem is that when the new data
> is created I need to create space for normals, texcoords, colors,
> vertex-indices and triangles, and get rid of the old structures. Because
> each of these is created with its own pfMalloc, they are all fairly
> small memory allocations, which then fragment the memory badly - making
> it almost unusable once free'd. Part of this is the application's fault,
> as it tends to need larger memory the longer it runs. A way of helping
> the matter would be to add up all the size I need for all of the data,
> then only make one pfMalloc for all of the data, then offset the
> pointers based on how much memory each attribute needs. This, combined
> with padding each pfMalloc up to the next 16k boundary, would allow me
> to reuse a LOT more memory since it would not fragment nearly as bad.
> The problem is that the pfGSetAttr functions need a full pfMemory
> structure with the header so it can keep track of the ref counts. I need
> less memory fragmentation much more than I need performer to keep track
> of my memory ( I have switched from pfDelete to pfFree and encounter no
> errors since all the memory is created/destroyed in 1 function and it
> does it in the right order ). Is there any way to use pfMemory and
> pfGSetAttr without having the pfMemory header and ref counts? I dont
> care if it is some low level hack - I need to reuse that memory! Thanks
> for any help.
>
> Doug Chism
> Lead Systems Engineer
> Dynamic Animation Systems
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
--
"One of the best-known folk theorems of software engineering is that
60% to 75% of conventional software projects are either never
completed or rejected by their intended users. If that range is
anywhere near true (and I've never met a manager of any experience
who disputes it) then more projects than not are being aimed at goals
which are either (a) not realistically attainable, or (b) just plain
wrong."
Eric S. Raymond - The Cathedral and The Bazaar
For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
This archive was generated by hypermail 2.0b2 on Thu Sep 16 1999 - 14:37:02 PDT