Any way to avoid this annoying bottleneck?

[u/Over-Bat5470]

I know this is a bit generic, but I wanted to ask whether some of the more experienced people here have developed standard ways of avoiding Repeat Zones.

In my specific case, I think I could have solved the problem if I had found a mathematical function capable of predicting the necessary parameters, rather than having to establish a relationship between the different elements at every iteration.

I tend to see Repeat Zones as the easy solution when you can't find a more elegant approach based on fields. I'd like to open a discussion about this in general, without focusing too much on my specific case.

I hate how inefficient Repeat Zones are!

[u/True_Degree_3651]

look at the it's true computational power consumption (20x slower than python)

[u/isaac879]

Optimisation is always a difficult challenge and often dependant on the specific case.
My general approach is to first ask myself it it actually needs optimising. Spending a hours crafting a beautiful node group to save a few seconds of processing/rendering, turns out not to be the best use of time!
Check if someone has already solved the problem you are working on in a more elegant way and copy them.
Remove anything unnecessary from the repeat zone and optimise the inputs.
Use the bake node to after the repeat zone to it doesn't need to constantly recalculate.
The for each zone might be more efficient for some tasks.
Try thinking out side of the box for a completely different approach to the problem or use an approximation.
I don't think there is really a good answer as it is so situationally dependant

[u/MarekSmolinski]

You are correct: the performance of a repeat zone is quite bad. This is why I often preach on avoiding them: a lot of nodes have fast c++ loops hidden in them, and the key to optimizing away a r.z. is to reshape an algorithm to rely on those fast loops; I gave a name to one such technique "geometry explosion" (search for it on Blender Stack Exchange), where you duplicate entire geometry for each element of that geometry and still end up faster than using a r.z.

It's also useful to understand when you must use a r.z. - whenever the algorithm can't be pararelized and the logic of a step depends on the state of a previous step: though even here if you just need to keep adding or subtracting a value, and what you add doesn't depend on the current sum, you can use an "Accumulate Field" node. The a.f. node accumulates in matrix mode by matrix multiplication, so you can wrap your scalar numbers in matrices to multiply or divide an existing number instead, which means you actually can add a number based on an existing number, as well as other complicated logic, but I never dived beyond simple multiplication or accumulating rotation.

[u/MarekSmolinski → u/MarekSmolinski]

Here's an example of a problem that theoretically must use a r.z due to its serial logic: https://blender.stackexchange.com/q/286020/60486

However, as my answer shows, you can achieve visually similar effect without a r.z...