I am finding myself in the following situation: a graph, using multiple subgraphs, each of them also using subgraphs, and at the end of this hierarchy, a "renderer" graph, having two possible forms: a fast renderer (fast to run and cook), and a "full" renderer (slow to run and cook). I can simply use either of them with a Switch node, depending on whether I was the fast or slow version. Problem is both renderers will be cooked, and there is a significant cooking time difference between the two, which here will be combined.
To prevent a significant cooking performance drop when using the "fast" mode (due to the cooking of the slow version which is actually not needed in this case), It seems the only way for now is to build two mostly identical graphs, one using the fast renderer, the other one using the slow one, so a lot of duplication and maintenance troubles.
Suggestion: add support for Graph Interfaces. A Graph Interface would be a graph with only inputs, parameters, and outputs, no implementation. A specific Interface input would enable to pass an implementation of the Interface so a graph could call it as it would for any other graph, except it would actually call the implementation of this Interface.
This way, regarding the example mentioned above, I would define a renderer Interface, pass a renderer implementation of this interface to the main graph using the rendering functionality. The cooking would then only take into account the specific implementation of the interface, hence would be much faster.
Note this would improve cooking performance in Designer for the above scenario, but not into other hosts using the SBSAR in a runtime form. Nevertheless, regardless of the potential performance gains in Designer, these interfaces would still be a nice design option.
AdChoices