20,741
edits
Howto:Troubleshooting Nasal Callbacks: Difference between revisions
Jump to navigation
Jump to search
Howto:Troubleshooting Nasal Callbacks (view source)
Revision as of 17:56, 6 February 2016
, 6 February 2016→Understanding Callbacks
No edit summary |
|||
| Line 163: | Line 163: | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| date = Feb 13th, 2015 | | date = Feb 13th, 2015 | ||
}} | |||
}} | |||
== Approach == | |||
{{FGCquote | |||
|1= We cannot really/easily identify "loops" per se - i.e. as far as I remember (Philosopher may correct me if I am wrong), we have to use what's available via die(), aka naRuntimeError, which really only provides 1) filename/path and 2) line number. | |||
However, this can be used to build a list of "active callbacks" that can be associated with their "origin", i.e. where the callback was registered to be invoked via settimer()/maketimer() or setlistener(). | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=275244#p275244 | |||
| title = <nowiki>Re: Nasal Callback tracking (timers & listeners)</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Feb 6th, 2016 | |||
| added = Feb 6th, 2016 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= What's available in C++ space are primarily: the event manager subsystem (SGEventMgr) which has two internal "queues" for keeping a list of callbacks that shall be invoked when a certain event (timeout) happens, as well as the property tree interface to register Nasal callbacks via the SGPropertyChangeListener API: | |||
http://api-docs.freeflightsim.org/simgear/classSGEventMgr.html | |||
http://api-docs.freeflightsim.org/simgear/classSGPropertyChangeListener.html | |||
At that point, all we have access to is C++ pointers, and pointers to Nasal data structures representing a function, so the best we can currently do is probably logging filename/line number per timer/listener and provide a list of those. | |||
Invocation is a different matter, i.e. we could maintain a counter for each known callback (C/C++ pointer) and reset/increment that per frame to actually determine how often a certain callback is actually invoked per frame/second/minute, analogous to the performance monitor. | |||
From a representation perspective, my suggestion would be to highlight per-frame callbacks in yellow, and everything that gets updated several times per frame (think FDM/AP-coupled coode) would be shown in red. | |||
Doing that will inevitably require patches to the SG/FG side of FGNasalSys, though. But the UI could be coded in Nasal itself, i.e. using the Canvas system. | |||
Equally, it might make sense to gather a total of timers/listeners at different stages of the initialiation sequence, i.e. how loading/unloading scenery/aircraft affects the global count of listeners/timers, and how many of those are actually pointing to C++ code vs. Nasal callbacks, and how that is affected by reset/re-init. | |||
Like you say, this is one of the more likely reasons for Nasal performance affecting the main simulation loop, probably even more so than the Nasal GC itself... | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=275244#p275244 | |||
| title = <nowiki>Re: Nasal Callback tracking (timers & listeners)</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Feb 6th, 2016 | |||
| added = Feb 6th, 2016 | |||
| script_version = 0.23 | |||
}} | }} | ||
}} | }} | ||