Hooray wrote:James recently activated his reset/re-init code, so that's probably what's causing this - and he seems busy investigating all bug reports, so I won't interfere unless this won't be solved within 1-2 weeks
Without having checked anything, I suppose it's related to callbacks still running, either property listeners, or timers - which is what used to cause such issues previously. One more reason, why we should investigate having an "active" callback list and exposing it to Nasal. Then again, as far as I know, James is shutting down all of Nasal, including listeners/timers. But that's the "low-hanging fruit" that I'd check first
..........
ok, it's interesting: it doesn't even need to be a different airport, I just used a bit of Nasal in a foreach loop to reposition at KSFO, and at around ~30 iterations, the whole sessions starts becoming dead-slow.
My previous comments were not quite correct though - because this is just "reposition", and not reset/reinit.
But even after 60 iterations, I am not seeing a crash here
But framerate is now single-digits and latency is ~2000 ms
So, should be easy to troubleshoot using the fgcommand-profiler
Ok, it's running now here: 100 reposition fgcommands, and one profiler-start fgcommand to see what's going on there
..........
seems like my original assumption wasn't too far off - according to the system monitor, it's "events" that's taking up all the CPU time, which is where Nasal timers (setlistener/maketimer) are registered.
---------
this shouldn't be solved within the next few days, I'll have another look - but it seems that exposing the size of the timer queue and printing it to the terminal should provide some insight:
https://gitorious.org/fg/simgear/source ... gr.hxx#L65............
confirmed, we were spot-on: I patched simgear's event manager to dump the size of the queues, and after ~30 resets, things are starting to grow massively, I am seeing rougly 160 active timers vs. just 15 by default
OnceI hit ~500 active timers, things are becoming real slow, i.e. 2000ms, but active timers start being "freed", and according to the profiler, the GC is kinda busy here, too
It takes roughly 60 seconds before the number of active timers is back to under 100 again
And according to pointer checks, there's multiple instances of a single callback running now - so it matches the whole scope of our discussion in the Nasal forum pretty well ... too bad that nobody would listem
But even after 5 minutes, things will not get back to ~15 timers, i.e. there remain ~80 active instances running