-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Durk Talsma wrote:
> > http://durktalsma.xs4all.nl/FlightGear/alloc-replaydata.png > > Here's actually the graph that forms the basis for my suspicion that memory > management is involved. This is a plot of execution time of the code snippet > > stamp("Replay_01"); > r = new FGReplayData; > stamp("Replay_02"); > > based on a slightly modified version of the one I committed this afternoon. > For the test, I didn't use the recycler, but created a new object for every > frame. Currently I register about 15 fps, so in a runtime of about one hour, > this code is executed about 54000 times. Of these 54000 calls to update(), > approximately 1600 triggered a timing warning, and the results of these are > plotted above. These results are quite puzzling: The majority of calls behave > nicely finish executing within 10 ms. A few can actually take more than a > second. This sounds like a page fault / thrashing problem, perhaps caused by memory bloat elsewhere. Can you get some system statistics from vmstat or sar? Also, it would be interesting to see if this problem happens while staying in the same geographical region i.e., there isn't any disk I/O happening as a result of scenery loading. Can you identify a known point in time when this wasn't happening? Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHAAP6eDhWHdXrDRURAoNEAKDedJB9A2J+04Mdgrdkhv18swZ73QCdF3ua h68CKDGyFbhw9wNX5ayTy94= =CSJH -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
