Re: [Flightgear-devel] Nasal property lookup performance

[James T. <jam...@kd...>]

> On 31 Jul 2017, at 23:39, Thorsten Renk <tho...@sc...> wrote:
> 
> Please test this with different numbers than 8000 as well - I seem to see strange non-linear behavior in the time with time per property increasing with total number of properties to be written (which I'm a bit at a loss how to interprete).

Okay, that would be very interesting, and would point to something pool based, such as the Nasal GC or allocator, or an allocator on the C++ side. (Something like listeners being slow ought to be linear)

> 
>> It's not clear to me whether using references from props.nas is
>> therefore "fast enough" or whether there is value in trying to improve
>> performance.
> 
> For well-organized code (aka writing only when needed, organizing the displays in suitable groups, staggered updates...), it's going to be fast enough. For a straightforward approach to complicated displays probably not.
> 
> A thousand properties sounds a lot, but every  update in translation is already 2 properties, combined with a visible flag and color information you're down to 166 elements you can update already.
> 
> If each of them is driven by reading a value from the tree you're losing even more.
> 
> Generally, if there is a way of making either method faster, it would affect performance in a positive way all over Nasal scripting because currently property I/O is in my view the largest bottleneck (especially of canvas).

One definitely doable solution: it’s easy for me to add native helpers to Canvas to set some properties from code directly, rather than using the canvas.nas wrappers which then use props.nas internally. This could bypass a whole ton of Nasal if that’s the issue. Of course this code will still have to update properties from C++, so I’d rather do the analysis first to see where the slowness occurs, since this could either be a very big win, or completely pointless based on that measurement.

Kind regards,
James