Talk:Nasal optimisation: Difference between revisions

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.