Using external variables and not using external variables, the running speed difference is 30 times!

[蓥飞308084024e44]

[蓥飞308084024e44]

[davescm]

I don't see the same here.

The version of Image_Thinning with the node input takes 14-16ms whether set to true or false

The version without the node input takes 0.83ms when set to its default of true but 14-16ms, the same as the other node, when changed to false.

I can't look further without the graph for Image_Thinning

Dave

[蓥飞308084024e44]

[蓥飞308084024e44]

Thank you for your reply. I have updated the test cases here:Update test case:running speed difference is 30 ti... - Adobe Support Community - 14032829

[Cyril Dellenbach]

Hi @蓥飞308084024e44,

Thanks a lot for reporting and for all the details.

We're taking a look at your dataset and we'll keep you updated on the subject.

Best regards,

[davescm]

I have merged your two threads on this subject to keep everything in one place

Dave

[davescm]

It would appear that connecting the Boolean parameter to a node input (or exposing it as a graph input) causes the node to report the longest route through the node (whether that is True -short route or False - long route).

Whereas keeping it as a parameter set within the node reports the node timing for the current setting of that parameter.

I wonder if this is by design, showing the longest calculation time for the node regardless of exposed parameter input settings

Dave

[Luca Giarrizzo]

Hello,

I will repost here my reply for this issue I sent you through another support channel, in case it is helpful for others:

When the 'input' parameter is set to False, the performance of both SBSAR instance nodes in the provided graph is similar. This points me to the likely cause of the performance difference.

This would be a known issue, which is caused by the way values are implemented in Designer.

I imagine there is some kind of switch in the SBSAR instance node graph that returns the original or processed input, depending on the 'input' parameter value.

In most cases, switches are optimised so that the unused branch is ignored entirely in the graph computations. This explains why the node renders so much more quickly when 'input' is set to True.

However, this optimisation cannot be applied if 'input' is a dynamic value.

Parameter values can be static or dynamic:

• Static: cannot be changed on the fly in compiled graphs (E.g., graphs in SBSAR), can be optimised to not be recomputed every time (see the Limitations section of this page to learn more);
• Dynamic: can be changed on the fly in compiled graphs, cannot be optimised.

That said, because of the way values are implemented in Substance graphs, they are always dynamic. This means no optimisation can be performed on node streams where the result is impacted by those values.

In the case of the SBSAR instance nodes in your provided graphs, both branches of the switch are entirely computed when using an input value to drive the result. Therefore, the performance will always be similar to what it is when 'input' is set to False.

Fixing this requires deep changes in the architecture of how graphs are computed and the Substance engine. Thus, it will take a lot of time.

Best regards,

[davescm]

Thanks for that explanation Luca. It confirms my thinking in my earlier response.

Dave.

[蓥飞308084024e44]

Yes, I need dynamic input values to determine where to stop the calculation.
In fact, this is an iterative algorithm that requires the result of the previous iteration each time. It would be a better choice if we can have some kind of iterator in the node graph, similar to the "for each" loop in Houdini!