On 13.04.2011 13:46, Frederic Bouvier wrote: > To reduce memory footprint caused by model caching, I added this code to the > begining of the main function of fgrun : > > osgDB::Registry* registry = osgDB::Registry::instance(); > registry->setExpiryDelay( 0. ); > > I suspect we can control the amount of caching the same way in FG
The default expiration delay is 10 seconds. Any texture/image/... which isn't referenced any longer should automatically be purged after 10 seconds. Reducing it to 0 shouldn't help too much - just save 10 seconds worth of memory. But it would void performance benefits when stuff get's dropped and then reloaded immediately, e.g. you do a sim reset or the MP connection has a brief drop-out (I sometimes see MP models disappear and reappear after a few seconds). The real problem should be elsewhere: * either the whole OSG caching system just doesn't work at all, i.e. it never purges unreferenced and expired data (I somehow doubt this). * we somehow haven't implemented the caching thing correctly (no idea what we could be missing) * or it's all our fault, our leak alone - more or less unrelated to caching. I think the latter is (still) the case. I already posted some weeks ago that I was seeing loads of leaked objects. I managed to fix a few things at the time http://www.gitorious.org/fg/simgear/commit/44f27b23d0209d2ee9f508c43def5636564bb302 http://www.gitorious.org/fg/flightgear/commit/4761a3cdcf04771819b3a8de9d018fca20c90ca6 http://www.gitorious.org/fg/flightgear/commit/8962477cfa10850cb459d7de754c9a435cc91293 but that wasn't all of it by far. Still looked "leaky as a sieve" to me :| and mainly affected MP models, clouds (global weather based) and SG animation stuff - and thousands of properties connected to these. The longer FG was running (or the more players joined and left) the more objects were leaked. And that was long before we enabled the OSG cache. I never ran FG for 6 hours with clouds & MP enabled though. But are we sure that the OSG cache itself really made a major difference now? The thing is that we do have a lot of "automatic pointers" (objects with reference counting) in our code. It's all our classes based on OSG and all the SGShared... properties/classes. It's very tricky to find out if everything is working as expected here, since it's hard to tell when something should be removed. A simple mistake somewhere (like a non-virtual destructor in a base class), a single object which doesn't get disconnected - and a huge object tree connected to it never get's removed. It'd certainly be worth to investigate further and fix more leaks - but debugging these issues is painful and requires a long and tricky hunt. Any help would be appreciated... cheers, Thorsten ------------------------------------------------------------------------------ Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
