Multiple cache regions in foreach performance

hi all

I am optimizing my draw patch. often I have a spread of objects, and neither all objects, nor all of their properties need to be updated on the same condition. Is it ok to have multiple cache regions inside a for each loop or could this create problems?

Is it good to “micromanage” things at this level or does it create a larger overhead in the end, if I use too many cache regions? When checking for incoming changes, does it make a difference if I check primitive datatypes or more complex objects?

1 Like

It really depends on your particular patches whether or not the overhead becomes an issue. And it’s obviously always much better to place the cache around a loop and not inside (if possible).

The changed checks can be considered very cheap as we’re using the normal equality which is defined as a reference equality (pointer comparison) for complex objects as you say (note that this also includes all collection types like spread or array). For complex objects you therefor need to take care upstream that you don’t create new ones with the same content unnecessarily. To identify which inputs trigger a cache region look at the circle inside the tooltip - if it’s filled, a change was observed. It’s rather common that you see changes where you wouldn’t expect any. For example spreads being created with the same values every frame.

ah yes! thx for the insight. so I guess most of my chach regions do nothing. as I understand a workaround would be to check my values with a “changed” node and then force the cach region. (to avoid updates from normal equality check)

Indeed - if you have your own idea of “changed”, use the force input pin. Like for example SequenceChanged will test each slice of a sequence (spread, array, etc.) for changed. The Changed node will not do much different than an input border control point of the region itself.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.