User talk:Philosopher/Optimization findings

From FlightGear wiki
Jump to navigation Jump to search

Nasal Profiling Framework

FWIW, Here are some pointers on how profiling support is implemented in other scripting languages like Python and Lua, maybe some food for thought:


Arguably, there are more of such scripts in $FG_ROOT (definitely in aircraft like the concorde).

Are you able to extend your script to provide optimization hints, i.e. temporaries that are re-created during each timer/listener-call, while having identical values during each invocation ? Maybe even identifying temporaries that end up being GC'ed after each call ? Would that be possible or do you need additional hooks ? I'd imagine, that sort of info could be pretty useful to have - especially because of the amount of Nasal code we have in various aircraft and Nasal submodules (bombable/local weather). So identifying expensive callbacks is one thing, but identifying potential culprits for each function would obviously be a great improvement.

  • identify temporaries (cached vs. not cached)
  • track GC invocations during/after callback invocation dealing with objects allocated during the call ?
  • identify temporaries that get GC'ed after each call
  • suggest to move temporaries to an outer scope ?

So this would still just be passive diagnostics, but it would allow developers to analyze and review their code accordingly, and it would also be a first step towards some form of optimization machinery, where a peephole optimizer could lift variables to an outer scope.

Ideally, we would add your diagnostics code as an optional mode to FGDATA, so that developers could analyze their code and identify potential issues like these, which would in turn allow core developers to reject contributions that not satisfy certain criteria, because of performance considerations.