FIXED: Erratic cook rates show up in specific circumstances

Have a very weird experience to report. I’ve been grappling with it for a while now with no idea how to reduce it to a repeatable phenomenon. For the record, there’s a few other scenarios that seem to also cause / impact the cook rate in my original network, but for the sake of simplicity going to focus on just this one I can repeat consistently!

If you open the attached file in the latest version of 099 x64 (win10) and move the mouse around the panel.

You’ll notice that the cookrates for the null floating not connected to anything appear as expected. once per frame.

However the other null connected to the switch DAT has a cook rate that is very erratic. This is impacting my networks performance greatly because this cook rate propagates downstream due to Touch’s Pull Cook System.

Is there a reason why this switch dat is causing the chop to cook so much more often? Or perhaps is this a bug?

Thanks!
Lucas
cookRateBug_datSwitch.1.toe (5.36 KB)

I also get different results between my razer blade and my desktop work station.

Razer blade gives me highly erratic 4-10 cooks per frame depending on how fast I move my mouse around.

my desktop gives me 2 cooks per frame at a bare minimum, pretty consistently. However if I move the mouse very quickly I can get the occasional 4 but it is either 2, or 4, or 0.

Interestingly enough, if I plug that null into a switch CHOP that has two constants for inputs, the cook rate behaves as expected. It’s only with the switch DAT.

Further more, if I bypass the switch DAT, and leave the expression (or export) in place, the cook rate still does it’s thing.

If I turn off the viewer for the switch DAT it causes this to go away.

Seems the viewer of the switch dat is causing some extra cooks for some reason?

One last piece of information, If I change the language param in the common page of the switch DAT’s params to NODE instead of LANGUAGE this also seems to fix the cook time…

Just discovered this and am mentioning it with out really realizing what it does, yet.

Does look like something odd going on. I’ll see if I can find anything.

Awesome thank you!

Looking forward to more info on this. multiple cooks per frame has been a hard to track down problem in several big networks lately.

Will be fixed in 2017.12640+. This should only be an issue if down stream DAT viewers from the null CHOP are on, as in I don’t think it should affect perform mode unless you have opviewers looking at DATs…

Ahh I hadn’t even thought to try debugging cookrates in network with all viewers off in my other network. Either way, thank you! and looking forwards to the updates as always.

Yes, a viewer counts as a pull, so if you have cooking issues, best to debug with the viewers off, and make sure passive is on for your Info CHOPs as well.

Thanks for the detailed bug report!