https://github.com/lucee/lucee-testlab/actions/runs/11594465851/attempts/1#summary-32282058911

FYI for Lucee 5.3 we have optimized the for loop so it reconized certain pattern and writes special bytecode in that cases, so maybe that change will also affect this ticket.

it is also unrelated to the for loop, it is simply about variable access.

ACF has a cache that somehow caches the last used variable name (when the variable name is a simple name with no dot inside). That cache is very limited and only works when you use only one single variable inside the loop. it seems to work like a very simple stack. This was introduced in ACF 8 as far as i remember.
In testcases this brings performance improvements but in real live applications it does not, because this is a unlikely scenario in a real life scenario.

We actually did test this with different applications by logging how many time it happens that the same variable name is accessed directly it was accesed before. In regular code (we did test with popular frameworks like coldbox) this was something not happen that match. i cannot remember the exact number, but it was below a 1%.

Like every cache we must assume that the ACF cache comes with a minimal overhead and if the cache not can be used, you pay that overhead. So in our opinion that ACF cache makes ACF slower not faster. But this is only assumption of course. But when we "disable" the ACF cache (see example code linked below) Lucee is faster.

It's likes volkswagen dieselgate, it only makes the car cleaner in a testscenario. but in real life it is not.

Please see the small change to the testcode (adding "local."), disable that cache and makes ACF slower again.
https://trycf.com/gist/9d63f9c806549e9079c1cc8798cb3621/acf2016?theme=monokai

I've analyzed this ticket a lot & compared with ACF 16. Actually IMO the problem with the loop, Lucee had some difference execution of loop compare with ACF 16, I've added comparison details as follows

Approx ACF 10 times faster than the Lucee.

Hi ,

In your above doesn't count a PRIME Number,

it just escapes the condition & improves execution time from 3427 ms. to 970 ms

changed to floating point as below

It takes same time as integer. In IMO, It's not a problem.