On Sunday 23 September 2007 10:28, Durk Talsma wrote: > Hi Fred, > > On Sunday 23 September 2007 00:20, Frederic Bouvier wrote: > > I used a profiler of my own : > > Excellent! This is almost exactly the type of profiling I hinted at > yesterday. I believe that this is a very debugging tool. Can we add a > (slightly modified version) of this profiling system to the actual simgear > code? >
FWIW, I've just committed a modified version of Fred's time stamp code (using SG_LOG, instead of cout). I've set the priority to SG_ALERT level, so that these debug messages will always be printed. We should probably demote that to something lower in a later stage (SG_WARN probably). For now, however, I believe that fixing the observed timing problems should be top priority. Running a few short sessions, I found the observed timing patterns very insightful, although I haven't been able to generate a full working hypothesis. Some observations: - Some small pauzes seem to be caused by consecutive calls to the systems controller and environment. Execution times of these systems is variable, between calls, but the execution time of "environment" seems to be just slightly longer than that of "controller": Subsystem Timing Alert : 18150 controller Subsystem Timing Alert : 20519 environment Subsystem Timing Alert : 47917 controller Subsystem Timing Alert : 49514 environment The longer and icreasingly growing pauzes seem to be caused by replay, possibly in interaction with some of the other subsystems. I haven't really found out what is going on here. Cheers, Durk ------------------------------------------------------------------------- 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
