Talk:Nasal optimisation

Nasal threading for SVG handling via svg.nas

I think the threading part can actually be used successfully without introducing fragility: As we discussed previously, the FG1000 is parsing a ton of SVG files, and that parsing is handled by Nasal (svg.nas) - it can relatively easily be dispatched to a Nasal thread, at the mere cost of delaying the property tree access (it already uses a stack internally) - which could be a perfect match for your PartitionProcessor.

For people to actually use your optimization tips, it would make sense to integrate those helpers with your MFD framework, also to provide an incentive for people to actually use it (use Richard's MFD framework = get better performance).

And in fact, it would also be possible to overload setprop/props.Node per MFD instance to transparently use your helpers, while that would not provide ideal performance, it could get some people going more quickly.

Back when we were profiling the FG1000, the one thing that would be required to use Nasal thread.newthread() API for SVG handling was delaying execution of code that expects certain SVG IDs to be around already - right now, the most common idom is a for-loop to traverse a data structure and get a handle to a bunch of SVG elements per SVG file, so that these can be individually update/animated. So we usually traverse a bunch of files to get a bunch of element IDs and then run all the initialization afterwards - if the "SVG initialization" workflow were to become a dedicated idiom as part of the MFD framework, Nasal could spawn a few worker threads, do all the parsing by getting file names/callbacks from vector and then use a partition processor to do all the property I/O spread across multiple frames that would then run in the main loop afterwards. Again, with the current FG1000 init I am seeing roughly ~15 seconds of delay due to SVG handling on less powerful systems, once SVG files are processed in parallel, that delay goes down to roughly 5 seconds - I haven't yet tried spreading out the callback handling to set up Canvas elements in separate frames, but I believe with your work, this could be a very promising way forward without introducing breakage (possibly using Emesary to register SVG files to be processed by worker threads) - and using a thread pool/job queue threads could still be optional, too. I think Stuart, James and jsb actually commented on the fact that they'd like to keep SVG handling in Nasal space due to the flexibility it provides, compared to native handling via librsvg (which would require some C++ work): Canvas SVG --Hooray (talk) 09:23, 5 December 2020 (EST)

Partition processor

Do you have any plans for recursively registered/invoked partition processors (PP) In other words, such that each recursively invoked instance is aware of the outer instance and its constraints ? For instance, let's say the FG1000 gets a top-level partition processor instance, would it be possible to limit its impact o frame rate/spacing such that page-specific PP instances could sort of "inherit" settings from the outer/top-level instance ? The point being, there is the long-standing idea to hook up a PID instance to help manage FlightGear frame rate/spacing by using [[1]], e.g. referring to James comments at [2]

The other issue being how the partition proessor deals with its job queue when new items arrive that may invalidate items still in the queue (imagine a MapStructure traffic layer still processing MP traffic when new positions arrive before the previous items are all processed)? Basicaly, this is asking how items in the PP queue are to be expired if necessary ? Thank you. --Hooray (talk) 10:56, 5 December 2020 (EST)