Re: [Flightgear-devel] OSG caching

[ThorstenB <br...@gm...>]

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