Curtis L. Olson wrote:

Hopefully David can answer the implimentation details, but I would like to point out that in many situations your code can do the "expensive" string lookup once at init time, cache the pointer to the node, and from then on, just use the cached node pointer to read/write the value. With this technique, there is an extra level of indirection over using a standard variable, but it still is very fast.

It's been a long time since I worked on the property system code, and other people have hacked on it since I've been there, but basically, Curt's right. Here's a quick overview:


1. Logically, the property system is a tree of labelled nodes rather than a lookup table. That means that if you get the value of /controls/flight/elevator, the property system starts at the root, looks up the first child named "controls" (in a list, since hashing gives no benefit for short lists), then looks up a child of the "controls" node named "flight", then looks up a child of the "flight" node named "elevator".

2. However, to speed things up, each node has an STL map attached for *caching* lookups, so when you lookup a node relative to another node, it will cache the result and get it from the map with a single lookup the next time.

3. Since every property value exists in a node, FlightGear subsystems often simply look up the node once and then manipulate it directly, just as Curt described. The node for /controls/flight/elevator will always be the same, even though the actual value changes. In YASim, Andy decided not to bother working through nodes and just goes straight through the lookup in #2, and I cannot see a speed difference against JSBSim. It wouldn't be hard to change YASim, though.

4. Note that all of the lookups can be relative to *any* node, so in the future, we can pass each subsystem a reference node at initialization time. For example, instead of running one copy of JSBSim lookup up properties in /, we could run three copies, one with the reference node "/vehicles[0]", one with the reference node "/vehicles[1]", and one with the reference node "/vehicles[2]". As long as the subsystems do relative property references (i.e. "controls/flight/elevator" instead of "/controls/flight/elevator", there should be no conflicts.


All the best,


David

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to