It would be really useful for optimizations to have a diagnostic tool (along the lines of the Performance Monitor) which could trace through exactly why any particular node is cooking.
While manually tracing through the network is possible, there are sometimes cases where it isn’t as clear. It also seems like it would probably not be too complicated to implement.
+1
We do have an old tscript command “opdepend”
which can list a node’s input, output and non-connected input dependencies.
That could be the start of it somehow.
Ah. I didn’t know that existed.
It would probably be fairly similar, though maybe at a lower level, and also including things like “this op is cooking because the viewer is shown on this other op that’s pulling from it”.
Is there an inverse to opdepend to find things that depend on a particular OP?
I believe ‘opdepend -o’ (outputs) may work.
But your right, saying ‘this node cooked because this viewer asked for the data’ would be a much more useful diagnostic tool.
Max/MSP has an interesting debugger that might work well with this that goes through the project in order of when all the operations happen, and colors the wires to show what’s cooking and in what order everything cooks.
Yeah… there are a lot of those kind of tools and editing features that I miss from Max (comments in patches, easier inline ui components, the debugger, json-based patch format, etc).
I still prefer TouchDesigner for anything visual though.
This information is also often available in the Performance Monitor. If you take a snapshot and find the node you are interested in, the nodes whose time usage bar it falls inside of (the nodes above it that have a time usage bar that overlapps theirs), is a node that was waiting for that node to cook before continuing on it’s work. Thus, the node above it was the reason it cooked.