we have tested and disabling Canvas brings performance from 11 fps on my new hardware (but 100ms latency, making it far smoother than my earlier 10fps which gave 200ms latency...) to 24-27 fps.
it would make sense to disable different parts of the Canvas, for example:
- disable rendering
- disable updates of the Canvas
That way, you can see if the problem is rendering related or if it's due to your Nasal code that may be poorly structured.
A Canvas that isn't updated at all, should basically render a static quad only - disabling rendering only (e.g. via invoking .hide() on the top-level root/group node), will still update things, so that you can determine more facts.
In addition, you can also check out other, lower-level, groups (or elements) to narrow down what is going on.
In the majority of cases, it's Nasal code that is poorly-structured and updating/rendering (re-drawing) the Canvas texture too often - the other common issue is a staggering amount of property accesses (getprop/setprop)
That is one of the reasons why I repeatedly suggested to check out Richard's MFD framework, which provides building blocks that can be used to better structure the Nasal code, e.g. using a "data provider" abstraction - which would mean that 100+ getprop() calls won't get executed, but use the memoized (cached) result from the first invocation during the same frame.
There's other optimizations that can be done obviously - but the first step is really doing some benchmarking first to come up with a theory what is going on, and then take it from there.
In general, Nasal-space data structures should be preferred over property tree use, if the corresponding state doesn't need to be "shared" - for example, Thorsten ended up restructuring his Advanced weather code (local weather back then), because he was using the property tree for all kinds of stuff that didn't have to live in the global tree.
These days, things are no longer as clear-cut unfortunately, especially because many fgfs subsystems don't really have any dedicated Nasal APIs (bindings), so that the property tree is the sole mechanism to set up AI traffic nodes, modes or talk to effects/shaders.