On Fri, 11 May 2012, ThorstenB wrote: > Not quite true. A significant part of Nasal-related frame rate impact is > caused by garbage collection. Its delay/jitter only depends on the > number of Nasal objects and their references which need to be searched. > Increasing the number of Nasal objects (code+data) existing in memory > also increases the delay.
It might be interesting to try my old patch that adds a separate thread that tries to run the Nasal GC when the main loop is doing other things and see if that gives any improvement. (It runs the GC for every frame which is rather wasteful, but I have idle cores here anyway.) http://sleipner.gidenstam.org/users/anders/FlightGear/sg-gc-3.diff http://sleipner.gidenstam.org/users/anders/FlightGear/fg-gc-3.diff It doesn't solve the bigger problem of the current Nasal GC needing to run uninterrupted and in mutual exclusion - but I see very few GC runs in the main loop here (the patch prints "** Nasal GC in main thread **" in the console when that happens) except during startup. IIRC it does not report when a main loop Nasal context has to wait for the GC thread to finish a GC pass but I could look into adding that when I have time - it would be interesting to know. As far as I know the code has not been tested on Windows. Cheers, Anders -- --------------------------------------------------------------------------- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
