Harald JOHNSEN a écrit :
> Melchior FRANZ wrote:
>
>
>> * Heiko Schulz -- 9/22/2007 6:19 PM:
>>
>>
>>
>>> Melchior always saying that it is not the issue with
>>> the setlistner- but I'm sure there is a problem with
>>> which causes this stutters.
>>>
>>>
>>>
>> And I'm sure it's not. I had the same with the f16,
>> which uses almost *no* Nasal, and the YF-23, which uses
>> no Nasal at all(?). (Of course, there's always the global
>> Nasal stuff, but there was much less at that time.)
>>
>>
>>
>>
> Can someone plays a bit with a profiler ? While a listener is nothing
> special, Nasal itself take a substancial part of the cpu time per frame
> (of course that depends on a few random parameter but I have between 20
> & 35 % of the cpu used in the nasal sources). And some time ago I was
> refering to the garbage collector that causes mini stutters and the gc
> was running on a period like 1 gc every 20 seconds at fg start and after
> some time it was like 1 gc every 10 seconds, the time spent in the gc
> was increasing too.
>
I used a profiler of my own :
cvs -z4 -w -q diff -u -wb -- simgear\structure\subsystem_mgr.cxx (in
directory I:\Devel\SimGear.plib\)
Index: simgear/structure/subsystem_mgr.cxx
===================================================================
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/structure/subsystem_mgr.cxx,v
retrieving revision 1.5
diff -u -w -b -r1.5 subsystem_mgr.cxx
--- simgear/structure/subsystem_mgr.cxx 21 Feb 2006 12:59:31 -0000 1.5
+++ simgear/structure/subsystem_mgr.cxx 22 Sep 2007 22:12:50 -0000
@@ -4,6 +4,7 @@
#include "exception.hxx"
#include "subsystem_mgr.hxx"
+#include <simgear/timing/timestamp.hxx>
////////////////////////////////////////////////////////////////////////
@@ -124,7 +125,17 @@
SGSubsystemGroup::update (double delta_time_sec)
{
for (unsigned int i = 0; i < _members.size(); i++)
+ {
+SGTimeStamp start, now;
+start.stamp();
_members[i]->update(delta_time_sec); // indirect call
+now.stamp();
+long b = ( now - start );
+if ( b > 10000 ) {
+ cout << "D : " << b << " " << _members[i]->name << endl;
+ int a = 1;
+}
+ }
}
void
It appears that it is the replay subsystem that creates long pauses
periodically, and sometimes the ai-model subsystem too :
( my traces : )
D : 12000 replay
D : 11000 replay
D : 17000 instrument20
D : 18000 instrumentation
D : 12000 replay
D : 12000 replay
D : 14000 replay
D : 19000 replay
D : 16000 replay
D : 18000 replay
D : 11000 replay
D : 22000 input
D : 13000 replay
D : 17000 replay
D : 14000 replay
D : 22000 replay
D : 18000 replay
D : 18000 replay
D : 18000 Traffic Manager
D : 17000 instrument13
D : 18000 instrumentation
D : 17000 replay
D : 23000 electrical0
D : 32000 systems
D : 18000 replay
D : 11000 replay
D : 16000 replay
D : 11000 replay
D : 11000 replay
D : 252000 input
D : 11000 replay
D : 12000 electrical0
D : 15000 systems
D : 11000 replay
D : 17000 ai_model
D : 11000 instrumentation
D : 11000 replay
D : 14000 replay
D : 18000 replay
D : 11000 replay
D : 12000 replay
D : 19000 replay
D : 15348000 replay
D : 16000 ai_model
D : 14000 replay
D : 11000 replay
D : 12000 replay
D : 14000 replay
D : 12000 replay
D : 15000 properties
D : 13000 replay
Very long pauses are caused by breakpoints in the debugger
regards,
-Fred
--
Frédéric Bouvier
http://frfoto.free.fr Photo gallery - album photo
http://www.fotolia.fr/p/2278 Other photo gallery
http://fgsd.sourceforge.net/ FlightGear Scenery Designer
-------------------------------------------------------------------------
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
