Time sliced chops are unique in that they require themselves to cook every frame to produce results that are always correct across varying fps and circumstances.
There is a great write up here about it:
When a node is being viewed in the network, via the node viewer and nothing else, this forces the node to cook, if it should cook at all. so if a lag chop is up stream, and you are staring at a null a few nodes down in your network, you’ll see it cook:
I know the gif compression makes it mard to see the wire animation, but it’s animating!
If you turn off the viewers for everything downstream of a timesliced node, and there are no other things requesting it (panel comps, renders, shaders, etc) then you’ll notice the noodle animation goes still .
So, if you are looking at a part of your network that seems to be cooking, if you know for sure that nothing will request it when in perform mode, then you can safely assume it will self optimize later when you’re not looking at it.
Performance monitor is a good way to check this while in perform mode, use the path to that component in your network, and click analyze. If you don’t see the node by name, it didn’t cook.
Also, when you middle mouse click on a node to get the performance info, it does take longer, not sure why - maybe just overhead for immediately requesting info from the chop. For that reason, this is not an entirely useful metric for anything other than comparative measures, if you want to know the actual cook time, use the performance monitor or drop an info CHOP down, and see it’s cook time that way.
All that said, if you have a need for things like lag chops, and lfo’s, and logic chops you’re going to have to make room in your performance expectations for their cooking every frame.
I have gone down the road of using tons of null chops as well with selective turned on, but I hazard against this as a fix all first solution, especially for complex / bigger networks because they have a nasty habit of getting delayed by a frame and causing any logic or visibility switching to get really glitchy or unusable. I’ve been unable to reproduce this in smaller more straight forward networks, so not sure entirely why it happens.
Also, null chops do incur a very small performance hit every frame that you will see if you check the performance monitor. This actually has added up for me in the past, when I had hundreds of selective nulls across many replicated sub networks.
There are ways to optimize performance though by changing how you use time sliced nodes. Here’s a few of my favorite work arounds / tricks regarding mostly chops - though it’s in no way comprehensive and the only ways. I’m sure others will chime in with some other great ideas and workflows:
-
Switching between static and timesliced - If the result of a timesliced chop is only needed under certain circumstances, like when the mouse is inside a certain panel, or when a certain button or state is active, then a great solution is to switch between a constant(still) value and the timesliced value. Something like this:
Notice that even though the lfo noodle is animated , and we are viewing this in network, the stuff after the switch is still. I use this trick a lot, as it prevents the need for null chops. Of course, the function of your patch has to be conditional to benefit from this, in the case that it’s always on, this won’t really help.
-
Move the timesliced parts as far down stream as possible - This one is easier to think of, but worth mentioning - move your timesliced data into a separate and parallel path, and do not merge it into your primary data flow until as far down stream as possible. Here’s a simple example of heavy processing happening above, and merged only at the end.
-
Keep timesliced stuff out of replicated containers if possible - This is something I used to do a lot, because it was convenient and usually more obvious how to achieve something when thinking inside a replicated module. However, replicated networks usually mean that is a dynamic part of your network, and any cook time you get in 1, gets multiplied across all of them obviously. Even if you prototype this way, always try and move it outside of the replicated area, when you can.
Here’s an example of lags inside each comp, this would not scale very well:
Here’s an example of the lag outside, after the join, with lag per sample turned on:
Lots of timesliced chops got the “XXX per sample” toggle added more recently-ish, and it is truly great. use this whenever you can!
I’ll leave it at that for now - hope that helps!