Nasal scripting language: Difference between revisions

Jump to navigation Jump to search

Nasal scripting language (view source)

Revision as of 17:38, 17 August 2012

2,153 bytes removed ,  17 August 2012
→‎Storage: property tree vs. Nasal
No edit summary
Line 58: Line 58:


Also, note that as of 05/2009, Nasal in FlightGear does not yet support any form of dependency resolution. In other words, there's no "import", "require" or "include" directive - this is also why most code in FlightGear is wrapped inside a _setlistener() call instead, which in turn waits for a FlightGear signal before executing the code (see below for details).
Also, note that as of 05/2009, Nasal in FlightGear does not yet support any form of dependency resolution. In other words, there's no "import", "require" or "include" directive - this is also why most code in FlightGear is wrapped inside a _setlistener() call instead, which in turn waits for a FlightGear signal before executing the code (see below for details).
== Storage: property tree vs. Nasal ==
With FlightGear's built-in property tree and Nasal's support for it, there are two obvious, and two somewhat competing, ways for storing scalar data: native Nasal variables and FlightGear properties, both of which can be easily accessed and managed from Nasal.
The advantage to native Nasal-space data is that it's fast and simple.  If the only thing that will care about the value is your script, they are good choices.
The property tree is an inter-subsystem communication thing.  This is what you want if you want to share data with the C++ world (for example, YASim <control-output> tags write to properties -- they don't understand Nasal), or read in via configuration files.
Also, native Nasal data structures are usually far faster than their equivalent in property tree space.  This is because there are several layers of indirection in retrieving a property tree value.
In general, this means that you shouldn't make overly excessive use of the property tree for storing state that isn't otherwise relevant to FlightGear or any of its subsystems. Doing that would in fact have adverse effects on the performance of your code. In general, you should favor Nasal variables and data structures and should only make use of properties to interface with the rest of FlightGear, or to easily provide debugging information at run time.
As of FG 2.4.0, retrieving a value from the property tree via getprop is about 50% slower than accessing a native Nasal variable, and accessing the value via node.getValue() is 10-20% slower yet. This is an insignificant amount of time if you are retrieving and storing a few individual values from the property tree, but adds up fast if you are storing or retrieving hashes or large amounts of data.  (You can easily benchmark times on your own code using systime() or debug.benchmark.)
In addition, it is worth noting that the Nasal/FlightGear APIs cannot currently be considered to be thread safe, this mean that -at least for now- the explicit use of pure Nasal space variables is the only way to exploit possible parallelism in your code by making use of threads.


== Using Hashs to map keys to functions ==
== Using Hashs to map keys to functions ==
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/53178"

Navigation menu