FIXED: TD parameters (or something else) optimaztion issue

Bugs
1

Hi!
2023.12000 Win 10

Here is an example:
Two containers are identical, but left one is 3x times cpu slower.
Both contains cooking and non-cooking ops inside
For the cooking ops left one utilize parent parameters the right one - child comp parameters.

parametersV2.toe (1.3 MB)

Screenshot (224)
Screenshot (224)1728×1128 101 KB

Cheers,
Alex

2

Taking a look

3

In case it will help:

For the left container
If non cooking stuff has Cooking Flag off initialy - it does not affect performancce, then do:

  1. Turn on Cooking Flag - almost no affect
  2. Go inside that container and back - signficant impact to performance
  3. Turn off Cooking Flag - still signficant impact to performance

Here is video:

And toe:
parametersV3.toe (1.3 MB)

Hope it will help.

Best,
Alex

4

Ah, thanks. We are trying to figure out what’s going on here.

5

Okay, word from the code mines is that you found something interesting but it can’t be fixed in official. Performance will be improved for this situation in the next experimental release. Thanks for report!

6

Awesome,
I am sure you ve already noticed that annotate comps bring huge impact also, even in perform mode.

Here is an example, just in case.

parametersV4.toe (24.7 KB)

Thank you!
And Happy New Year!

7

Will look into this one too. There are always too many scenarios to test each of them, so feel free to keep sending in your tests

8

We’ve made an optimization where Annotate parameters will no longer be evaluated unnecessarily. This will be available in the next Official Build we post after 2023.12230

9

Following that, there will be some further optimizations in an upcoming experimental build.

10

Hi,
2025.32460 Win 10

Became even worse for the parent vs child custom pars:
16 ms vs 4 ms

Lots of annotate example is slightly better:
10 ms vs 4 ms

Cheers,
Alex

11

oh. Thanks for the new information.
We’re having a look.

13

Hi,

Finally managed to localize this one properly — 2025.32820 Win.

Root cause: TD re-validates all expressions/binds inside a non-cooking panel sub-network on every parent-parameter change, even though nothing there cooks or renders (even inside .allowCooking = False subtree). Needs all three: (1) a root COMP’s pars change every frame, (2) something inside listens to them (e.g. a Parameter CHOP), (3) there are expressions/binds in non-cooking panel COMPs anywhere inside (baseCOMP / regular ops are fine).

Two more things:

  • Cost = (N changed pars) × (N expressions/binds) — it re-checks all of them per-parameter, not once per change event.

  • Binds survive a reload (cost from startup); expressions don’t (need to render the subtree once to trigger).

Full write-up + minimal repro (bugRepro / bugWithReload) are inside the toe

[UPDATED] - same happens if any other non-panel ops are using panel COMPs parameters (/project1/bugRepro1 example)

lotsOfStuffBug.toe (43.3 KB)

Cheers,
Alex

14

Sorry for the delay response. Our next experimental will have optimizations that reduces the issue.