Unjustified loop slowness (bug?)

Here is a native julia set filter - but the render time is insanely high / freezes, even for a few iterations (3-4 iterations). Me thinks the loop machinery needs oil!

Native Julia Set.ffxml

I might be mistaken, but no coordinate space branching is going on here, i.e. there is no spatial distorter involved (offset, noise distortion etc) and it is the same internal x and y that is used. This should not be a problem, but something is surely eating up performance.

Per my logic, which may be wrong, ANY branching (regardless of it being coordinate space or not) inside a loop would cause an exponential amount of components and recursion.

If you increase the iterations in the attached filter to 7 it starts to grind to a halt and this would be due to recursion at the rate of 3^n just because of branching into 3 inside the loop. There is no coordinate space branching involved.

That is, regardless of anything else, this loop would unroll to 3^7 = 2187 copies of itself at 7 iterations. As I understood it, this was the exact point of the explosive recursions warning?

Honest, I don't think it makes any difference in terms of recursion what components the branching goes into (except of course when it comes to memory management of the internal bitmap cache).

Explosive branching.ffxml

Is the same as this (at five iterations):

Sphinx, looking at it again, I am starting to think that due to multiple serial branching inside the loop of the Julia fractal there may even be (2^n)*(3^n+3^n)*(2^n+2^n), i.e. 6912 sample calls to the accumulator per pixel already at 3 iterations, which would certainly explain the slowness.

Probably yes, but we don't yet have any infrastructure for showing warnings on component's output.

Quote
If the sample cache is NOT working like it used to

The sample cache always worked this way, it just wasn't as noticeable because there was no repetition. We noticed it when we were rewriting sample cache to support Loops.

Vlad, is there some quick fix we can use to re-enable the cache hits? I'm thinking in lines of "place x component right after the accumulated component, place y component right before the loop accumulator input"?

Quote
Sphinx Vlad, is there some quick fix we can use to re-enable the cache hits? I'm thinking in lines of "place x component right after the accumulated component, place y component right before the loop accumulator input"?

Unfortunately, no (or, rather, I'm not aware of any). The quickest fix is to go through get_sample() methods of ALL COMPONENTS, including the obsolete ones, and refactoring their use of a certain rendering_data struct according to the new policy, then re-testing them all so that a) their RGB output remains the same, b) the AAZones / AAEdges aren't broken and have the same pattern as before, and c) the rendering time when looped-with-an-exponential-recursion stays the same or is improved.

That was easy! No grouping needed. You should consider saving a few rainforests by at least adding proper caching at the accumulated output

Native Julia Set.ffxml

Now imagine getting that inefficient script out of there Anyways it seems to work that Julia thing, however the normalized iteration ("Position") did not turn out as expected - we should see gray tones according to "bailout" (the threshold) iteration.. I don't get it

Not sure what that bitmap stuff is about. The custom sample cache script probably don't go well with spatial distorters (you probably need to place a new cache script at their outputs), or place copies of the cache script at the accumulated componet, one for each distortion "channel" (i.e. each new set of X,Ys passed down from the Loop Accumulated).

"Force Bitmap": Wouldn't it help (in some cases) to have a component that rendered the downstream image as a bitmap so that subsequent calls would not have to go further down than the bitmap component to fetch the value? (Like is the case with some existing bitmap components, AFAIK)

Ok, great, thanks. Here's the pared-down version. It runs okay up to about 8 iterations, probably pretty useless in the current form at any higher iterations (Although they are not that necessary in this case). It would certainly be interesting and useful to see if something can be done to speed it up at higher iterations, for it will definitely help in other recursion-style filters.

Loopy tree.ffxml

Ok, all those distorters destroy all caching options :-/ You have 3 separate coordinate branches (4 if we count the randomizer drain, but that probably has little impact). Those will branch out x3 for each iteration.. that REAL exponential explosions going on here

I'm not sure there is a fix for this really, besides radical redesign. I'll let you know if I figure out anything interesting.

If you can render the branches directly instead of transforming some fixed shape, that might help in both areas (i.e. performance and uniqueness of branches). Example: Some components have a rotation parameter - using that instead of a post rotation component will not create any new coordinate branch..

This attached example seems to shed light on something amiss with the threshold in a loop. At 10 iterations the blend component is 20x faster than the threshold component? Usually the threshold is more efficient than the blend.

Threshold Bug.ffxml