pop quiz, which one is fastest?

a = [].set(1, 10000, "zac");

c = 0;

timer type="outline" {

loop array=a index="b" {

c++;

}

}

dump(c);

d = 0;

timer type="outline" {

a.each(function(e){

d++;

});

}

dump(d);

f = 0;

timer type="outline" {

a.each(function(g){

f++;

}, true);

}

dump(f);

I'd expect the first one. I'd also expect to never be looking at performance gains by checking what iteration construct I was using.

I think you are probably demonstrating a weakness in cftimer for parallel execution

Oh yeh, just noticed the

true

on the last one.

nothing to do with cftimer

#spoilers Running the code... the last one was the slowest to come up with an incorrect answer. "kewl"

yeah, coz it's about thread safety, which causes the overhead too

So looks like

each

doesn't actually block until all threads have completed before returning? That's a bug innit?

for the last one? nah, you need a lock around f++

I get a result of [not 10000] when I run that code. I get it's running each iteration in its own thread (from some pool of available threads), but it should wait until all of them are done before continuing, shouldn't it? Or is it the non-atomic nature of

++

that's causing a race condition?

the later

OK cool.

(reading from 2013 in case it's not clear to anyone what we're on about: https://blog.adamcameron.me/2013/03/no-operators-are-not-thread-safe.html, and maybe the article it links to)

it's also mentioned in the docs https://docs.lucee.org/guides/developing-with-lucee-server/operators.html#demonstration-of-unsafe-threaded-behavior-with-and-operators

Shouldn't that "not thread safe, see below" thing be on ALL the compound operators?

good catch

curious though — what kind of “_thread safety”_ is going on in the parallel one that causes all the overhead then? is it locking when reading the array

a

to fetch the value of

g

for each iteration for example? or is it like pagecontext stuff? or is it overhead of creating the threads and checking the status?

pageContexts and os threads

And that perf issue is largely mitigated by those two tickets you cited?

nope they are concurrency bugs. for your mental model, parallel is for doing heavy tasks, it has an overhead due the the isolation required, it's simply not suited for doing little tasks

Right to the overhead is "per iteration", and when the loop is not some contrived amplification to demonstrate the point, the innate overhead disappears into the background noise, for all intents and purposes.

yeah. would be nice to figure out a way to optionally allow using a super lightweight page context, at the moment we pack the entire house up (request) just to pop round the corner to grab some milk

I would say that this is the problem with second-guessing implementation requirements @ language level.

it's also a case of if you are doing something for performance reasons, you need to profile it