Property Tree Performance: Difference between revisions
No edit summary |
|||
| Line 30: | Line 30: | ||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||
somewhere in SimGear/props there should be some kind of standalone C++ benchmark that David M. originally came up with and that Andy later on used to test his assertion that he could directly use properties (instead of properties tied to raw C++ PODs) in YASim (and he ended up being correct). | |||
<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=296421#p296421 | |||
|title = <nowiki> Re: Nasal must go </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Oct 9th, 2016 | |||
|added = Oct 9th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
For a more recent benchmark/test case (self-contained via the Nasal Console), see: | For a more recent benchmark/test case (self-contained via the Nasal Console), see: | ||
Revision as of 14:21, 25 February 2017
| This article is a stub. You can help the wiki by expanding it. |
Background
getNode("foo") and getChild("bar") consumes CPU while setFloatValue() seems to be quick.[1]
when writing to the property tree. Yasim creates ~250 surfaces for the CRJ700 and ~150 for the Citation II If I try to write data for those surfaces to the property tree (at FDM rate), frame delay rises rapidly, if I write more than 4 or 5 values per surface. I use getNode(), getChild(), set/get*Value()[2]
That seems to be about the I/O speed of the property tree. Don't do it at FDM rate for starters, do it only as fast as you actually need and stagger the process.[3]
somewhere in SimGear/props there should be some kind of standalone C++ benchmark that David M. originally came up with and that Andy later on used to test his assertion that he could directly use properties (instead of properties tied to raw C++ PODs) in YASim (and he ended up being correct).
For a more recent benchmark/test case (self-contained via the Nasal Console), see:
Howto:Canvas Path Benchmarking
Property name lookups are slow, there are some tricks to optimise that we could do, especially using a global hot cache. This would also allow an easy way to fix problem cases, by taking the hottest entries and fixing their call sites to cache the node. The first thing, however, is extending the existing unit test to do some basic benchmarking of reads & writes, and name lookups. And then the same but in the presence of narrow and broad listeners. [6]
References
References
|