Patrick is writing because we are running into an issue with long running applications and we are beginning to suspect fragmentation.
Basically, we have a long running application that does a huge amount of allocation and freeing of OpenSG resources. Just to quantify this a bit, our application is meant to run nearly 24/7 and during normal usage it will routinely page in and out textures and graphics objects to the tune of several hundred (or thousand) field containers per minute. In stress tests, we have easily gotten to the point of having tens of millions of field containers allocated an deallocated within a few hours of testing. The issue we are seeing is that memory usage is increasing as if there were a memory leak, but the number of non-NULL field containers remains stable around 20-30K. After reading up on it a bit, we are wondering if the virtual memory space is being fragmented. That said, as you point out we really want to prove it before trying to optimize it. Unfortunately we haven't found any good tools for detecting memory fragmentation and showing it to the user. Any one know of such a tool? -Allen On Tue, Jan 13, 2009 at 5:38 PM, Dirk Reiners <[email protected]> wrote: > > Hi Patrick, > > Patrick Hartling wrote: >> Has anyone ever tried to customize memory allocation of field containers? My >> hope is to address potential memory fragmentation issues resulting from >> frequent allocation and deallocation of field container objects--assuming >> that we do find that to be a problem. Specifically, I am thinking about how >> to change the allocation of custom field containers that are written as >> extensions to OpenSG. I was skimming the code and started thinking about the >> possibility of specializing OSG::FieldContainer::newPtr<T>() for a given >> custom field container type, but maybe it would just be easier (and less >> arcane) to overload new and delete for the types in question. >> > This is one of those things where I always have to restrain myself and > meditate to the Knuth mantra: "Premature optimization is the root of all > evil". Before going through the pain of doing something like that I > would wait until it is a real problem and then try to use a different > memory manager like for example Hoard (http://www.hoard.org/) and see if > that fixes it. > > Just my $.02 > > Dirk > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
