Am 2013-04-14 14:30, schrieb James Turner:
>> Extend Nasal property methods to support relative paths.
>>
>> All methods exposed to the Nasal props module now accept an
>> optional first parameter refering to another node by a relative
>> path.
>
> I'm a bit torn on this change; making APIs more flexible is usually a
> good thing.
>
> However, the cost of property path parsing has previously shown up in
> profilers as a source of dynamic allocations and overhead.
I haven't looked at it in detail, but why are dynamic allocations needed
for parsing a property path? If this is the case we should to some
profiling and rework it if needed.
> Historically, on the C++ side; I can believe that in Nasal the extra
> parsing overhead is lost in general Nasal overhead, but still, the
> idea of the existing API was to force you to design & work 'the right
> way', i.e cache leaf leaf nodes as objects, instead of repeated
> referring to leaves by a relative path.
>
> If you just want a quick and dirty way to read one property, we have
> getprop / setprop - for any other use, you should be doing what the
> API already supported; getting a props.Node object for the leaf, and
> then manipulating it with no further string/path handling. At least,
> I would prefer that getValue and setValue did not support this, since
> it will surely encourage convenient-but-inefficient styles of use.
>
> (I would also be happy to extend props.nas with helpers to make the
> above syntactically more compact, but I think such sugar can all be
> done on the Nasal side)
One thing I thing I want to achieve with this changes is to make the
Nasal props API more similar to its C++ counterpart as this makes it
easier to use if you are using both the C++ and the Nasal API.
Also someday I want to refactor nasal-props.cpp to use cppbind, where I
want to export as much methods as possible with exactly the same
signature than in C++.
Especially if using properties seldom (eg. only for initialization) the
relative versions are probably even faster, as the Nasal overhead is
lower. Eg. consider the following Nasal code used to initialize some module:
var cfg = props.globals.getNode("/my/config/root", 1);
var x = cfg.getDoubleValue("x");
var do_it = cfg.getBoolValue("do_it");
Using getprop on the one hand does not allow getting a property
converted to a given type and on the other hand is tedious to use for
more than one property, as one has to assemble the according property
paths (which is definitely less efficient than using a relative method).
Tom
--
Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org
------------------------------------------------------------------------
Student of Computer Science @ Graz University of Technology
------------------------------- Austria --------------------------------
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
