Base Comp - Cooking Optimization

Wishlist and RFEs
, , ,
1

I’m not sure if this would be considered a bug, optimization idea, a feature request, or if I’m just not getting something (highly possible).

I’m trying to optimize my large network. I’ve read loads of documentation and watched the 3 excellent TDSW videos on the topic.

In my networks I make heavy use of Base Comps with custom parameters. What I find troublesome is that anytime a comp’s parameters change, everything inside that comp referencing it will also cook… regardless of if it has no bearing on the final output or anything downstream. I’ve attached an example to illustrate this.

FX-Pipeline-Cook-Test.toe (6.3 KB)

Screenshot 2023-10-25 at 13.41.06
Screenshot 2023-10-25 at 13.41.061008×900 54.8 KB

I discovered a workaround by using a Parameter CHOP and passing that into a Switch before using any of the pars in my comp (b/c Switches seem to have this magical property of not cooking things when it’s flipped off). So I flip the switch based on some value/heuristic determining if my comp is active or not.

Screenshot 2023-10-25 at 13.41.25
Screenshot 2023-10-25 at 13.41.251336×552 34.5 KB

It seems liberal usage of custom comps & pars should be encouraged/optimized as it helps keep everything tidy and decoupled. And this workaround is quite tedious to implement/maintain in every single comp. I wonder if there is a more general solution to this problem?

Before I knew better I looked into disabling the Cook flag, but now I know this is a bad idea. So it seems like this is not really solvable in an elegant way via a user-built mechanisms, as we don’t have any way to fully disable/enable cooking of a portion of the network at runtime.

Perhaps TD could generally optimize for the case where no downstream effects are possible… which seems complex, but doable.

Or perhaps the Base Comp could come with an “Active” toggle (similar to Ops like Cache TOP). It’d be on by default, users can add custom expressions to enable/disable it. When it’s on everything functions as it does today, but when it’s off TD would know not to cook anything inside of the comp (or at least not cook anything based on the parameters). Essentially TD would do the same Switch optimization trick but every time a Comp parameter is evaluated based on this flag.

Thoughts? Other ideas?

Looking forward to your feedback.

2

Hello @hekuli,

I think it depends very much on what is referenced in networks. In your example a LFO CHOP has it’s Reset parameter triggered and even if it has no current influence on the output, the reset needs to be registered to accurately calculate a value when the LFO is actively used later on. For example an expectation would be that a LFO with a Frequency of 1 at 60 fps would produce a value of “1” after looking at it 10 sec after it being reset.

cheers
Markus

3

I see. That makes total sense.

I guess for many of my cases though I would be fine to accept the incorrectness in order to get the performance boost… or at least to having the option to choose the behavior would be nice.