On 03.03.2011 09:47, thorsten.i.r...@jyu.fi wrote: > The total time to load a configuration is really proportional to > > (number of objects) x (texture size of a single object) So maybe the textures aren't really shared. What's worse - and slightly related: I ran a memory analysis some weeks ago, to identify "true" memory leaks (that is memory leaks triggered at source code locations which over time increase indefinitely). I found that the MP aircraft and clouds are a major cause for FG memory leaks. The more MP aircraft were loaded and unloaded (obviously not properly unloaded though), and the more clouds were displayed (and also not properly unloaded), the higher the number of leaking memory elements gets (and the higher FG's memory consumption gets). Another huge memory leak is caused by properties. The leaking properties may be a result of the other leaks though (they might still be referenced by leaked clouds or MP aircraft models), though there could also be a separate issue. I only checked the number of memory elements - so not sure which leaks will actually hurt memory consumption the most. But at least it was pretty obvious that we have some bad issues in these areas.
I'm currently busy with other stuff. But checking on what's going wrong with loading/unloading clouds and MP models may be worth a closer look. cheers, Thorsten ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
