ChopExec abnormally high cook time

Bugs
,
1

TD 2023.12120 Win11

I’ve made a comparison between ParExec, ChopExec and DatExec reacting to the same event (an LFO CHOP set to pulse) doing a super simple task, adding 1 to a Constant CHOP’s value through a Text DAT script. All this is inside a Base COMP, and only one “type” at a time is active, measuring Children CPU Cook Time.

Here are my findings of average cook peaks:

  1. ParExec avg: 0.0075 ms
  2. ChopExec avg: 0.075 ms ← 10x compared to ParExec!!!
  3. DatExec avg: 0.015 ms ← goes through CHOP to DAT, but still less than ChopExec!

image
image1177×822 47 KB

The reason I think this is abnormal is that even DatExec, which requires the CHOP to be converted to DAT, is more performant than just CHOP alone.

Are CHOPs simply just less optimized for this?

Here is a file for testing:
exectest.toe (7.3 KB)

EDIT:
To add to this, doing a more complex task that is triggered by either a Pulse param’s ParExec or a CHOP input’s ChopExec (Off to On) the difference is also close to 5 times; 0.03 ms vs 0.15 respectively. So the fact that the extra processing stays as a multiplicative difference when scaling up the processing task, is pointing at a bug under the hood?

1 Like