Rework constant folding? #1539
Description
Superseded by the work done in #2232:
Keavon: What's the latest on #1539?
TrueDoctor: This will be part of the new context beased caching strategy stuff
Keavon: Should that issue be closed?
TrueDoctor: I think so, we removed the behaviour described in the issue in the context pr
Currently when adding nodes to the node registry we essentially constant fold all nodes (except for the async nodes) by basically evaluating them at compile time. This is done to allow us to compile chunks of the node graph which is very important for performance (without this we need to do one heap allocation per pixel when doing image processing -> we could try to use something like smallbox to circumvent this).
Still the current state is pretty confusing (choosing which nodes should be async etc.).
The let node is also not very pretty, we could think about making the editor api a value node which nodes can depend on and move the footprint out of the editor api.
We could then implement a proper compilation cache by traversing the graph from the root and computing stable node ids on subgraphs which can be used to query the compilation cache.
This would decouple the speed optimizations from the actual node implementation and pave the way for a compilation server providing implementations for compiled subgraphs. Ideally this would also allow us to const eval the shader compilation to move the shader compilation from graph runtime to graph compile time.
I'd also like to experiment with running a wasm interpreter in wasm as a polyfill until we have proper dynamic linking support to basically have the ability to execute and optimze arbitrary graphs.