clementsparrow suggestion: Allow skipping rules at the end of a loop if nothing has changed since last iteration

[increpare]

again, not benchmarked and no huge boost seen on unit tests (but few unit tests actually use loops), but I guess it can be useful. If you want to implement it too, you may want to have a look at the previous commit too, because the edge case that I removed was complicating the implementation A LOT (the edge case is when a loop is empty or there is no rule after the loop. It causes the inner loops of generateLoopPoints to fail finding the first rule after the loop keyword, and you fixed it by closing the loop at position rules.length, which I changed for rules.length - 1) ( https://github.com/ClementSparrow/Pattern-Script/commit/93502f561aa25f4572bf998cf8a64dfb71c570e2 )

Things future me needs to understand:

• what I do right now
• what this does,
• what's an example that shows the difference?

[ClementSparrow]

Oh yeah, you're right, I forgot to explain what it does. Say you have :

startloop
    rule1
    rule2
    ...
    ruleN
endloop

• rule1 is applied once, and then all rules rule2...ruleN are not applied.
• you loop back, because rule1 made something change, so we need to try another pass through the loop.
• but in that second iteration through the loop, rule1 is not applied (obviously it cannot apply, since if it could, it would have in the first iteration. But that's not the point of this optimization).
• what the optimization does is skipping rule2...ruleN in that second iteration and exit the loop directly. Indeed, there is no way these rules could apply since nothing has changed since the last time they were tried.

[increpare]

Ah cool; makes sense :) [thanks for the clear explanation!] I guess this could be applied on a group-level as well. 🤔

[ClementSparrow]

I just pushed a commit that does. But I have one unit test failing, I think it's because of randomness but I'm investigating it.

[ClementSparrow]

Yeah, It was because I made one less loop before stopping, so it messed with randomness. So, apparently, the speed boost on the unit tests is ~2%.