David Megginson wrote: > How big is the hit if you simply delete a higher-level node and let > plib delete all of the branches and leaves underneath automatically?
Probably equivalent. The overhead is usually in all the per-chunk bookeeping, not the function calls. We could try playing games with operator new, I suppose. We know for a fact that all these objects will be deleted at the same time, so we can in theory do much better than a general purpose allocator. The apache webserver has a similar issue -- they have lots of code that needs to do allocation from disparate areas, but they know for a fact that all of this stuff will be obsolete once the current request finishes. So they have a "pool" API where handlers can go for memory without all the bookeeping overhead. The request just doles it out as needed and frees it all at once. Code that needs "destructor" functionality can register a callback that will fire before the free is called. In our situation, this should work pretty well. It might need some hacking in plib to make it work cleanly, though. Lots of work, but with real performance benefits. Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
