I have meanwhile, sorry - your response was more constructive than I anticipated after the introductory "banter"

With that being said, I have taken the code posted in the wiki and reworked it a little (so far without any of your feedback) and have also executed the whole thing using the built-in profiler, which confirms that the property I/O is the bottleneck - and in fact, the problem is that it all goes through props.nas largely, which adds several layers of indirection (unnecessarily) - the setValues() and setChildren() logic can be easily expressed in C++ space using ~50 lines of code (all of which already exists in nasal-props.cxx).
I think that this would be a particularly low-hanging fruit to optimize this particular use-case - in the long-term, it would however make sense to port all/most of props.nas and move it back into C++ space for all the reasons that James, TheTom and Philosopher originally suggested (using Nasal/CppBind).
Apart from that, there are also Canvas/Element-specific optimizations possible, such as reusing the Canvas.Path node/element when resetting those paths.
Overall, it would also make sense not to set hundreds/thousands of properties, but really just build a single SVG path/command stream and set a single property and take it from there.
In summary, I don't think we've hit any "hard" limitations so far.
http://wiki.flightgear.org/Howto:Canvas ... rking#Code
PS: I was trying to come up with a reproducible test case to easily benchmark this and profile the underlying code, to be sure that we don't just know that this is "property related", but that there are no bugs like the leaking effects listeners contributing to this.