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 - 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)