On Sunday 21 October 2007 11:10, Melchior FRANZ wrote: > * Melchior FRANZ -- Thursday 18 October 2007: > > The good news: I have a Nasal binding/script cache almost finished. > > I don't know yet if it makes a huge difference, [...] > > That's now finished and, as expected, makes firing of bindings between > 20% and 90% faster. But I doubt that it will improve any stuttering > problem that some people have. (I still don't have *any* such problem. > I had in the past, and I've only changed the kernel version, libc, and > the nvidia driver since then. Same old crappy hardware.)
Sounds good. As other people have commented, it seems like the better the hardware the worse the problem. > > While working on the script cache, I noticed that Durk is right about > Nasal's garbage collector (GC). It *has* a bug. And Nasal listeners > trigger it just like keyboard/joystick bindings and possibly also > settimer() calls. I was quite surprised to see that the refcounter > of some SGSharedPtr nodes became bigger and bigger. Apparently Nasal > allocates them, but doesn't free them anymore. > > And after around hundred times moving the joystick's throttle lever > and a lot of switching the view, the number of node references is: > > 1067 /input/joysticks/js/axis[3]/binding > 1138 /sim/current-view/view-number > > So, Nasal has now over thousand unfreed references to the nodes. > And indeed, this matches a counter that I had added to nasal-props.cxx. > There are many more SGSharedPtr allocated than freed! Unfortunately, > Nasal internals aren't exactly my strong side, so I'll have to leave > that to Andy. :-) Okay, I'm at least glad we found something in that area. Hopefully Andy can shed some light on what might be going on. > > PS: the timing alerts are getting quite annoying. They pointed us to > some weak spots, but that's it. They will hardly help any further > to fix the stuttering problem. (And the warning code isn't exactly > written efficiently. It rather *contributes* to the problem. ;-) Well, the idea was indeed to demote the alerts to a lower priority once we get the hang of what's going on. Once a few people can confirm that the growing interval pauses are gone, I believe we're ready for that. Until then, I would like to keep these warnings on alert status, however. While working on this, I do believe that having access to some sort of timing statistic is important for future program development. In an offlist discussion last week, Curt mentioned that once upon a time (probably preceding the subsystems manager, and the property tree) we had this possibility. I am working on reimplementing that idea for the subsystems manager, using a simple sample statistics class. The idea is to collect total execution time of each subsystem and keep track of mean / min / max execution time for each subsystem. I've been experimenting with that a bit this morning, and the results are interesting. Obviously, these statistics should only be collected and printed when explicitly requested (i.e. using an option / property). As for programming inefficiencies, time stamps are collected in a rather non-intrusive way, and printed after subsystem execution, so I don't see how that could contribute to the problem. Cheers, Durk ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
