random: Perform fewer iterations if SKIP_SLOW_TESTS is set

[divinity76]

people running with SKIP_SLOW_TESTS don't want to wait for 1000x iterations of each engine. also 10x iterations should be sufficient to catch many potential issues

[TimWolla]

Thank you for the idea. I've applied this check to additional tests and made some small changes to your changes (increasing the numbers a little and turning the ++$i back into $i++ for consistency).

[divinity76]

Thank you for the idea.

yw!

I've applied this check to additional tests

Nice!

turning the ++$i back into $i++ for consistency

Have you ever really thought about what $i++ actually means? It means:

1. make a copy of $i
2. increment the original $i
3. return the copy.

now ask yourself, in this line of code:

for($i=0;$<9;$i++){}

do you really want PHP to waste time creating 9 copies of $i, just to immediately discard the copies? why would you want that?

In C and Javascript, the compilers are smart enough to automatically optimize post-increment to pre-increment, gcc 3x does this on -O1 and above, but the PHP interpreter isn't. in PHP, $i++ is slower than ++$i / $i+=1 (maybe PHP8's jit does it, i haven't checked, but PHP7 doesn't)

[TimWolla]

I understand how the pre- and post-increment operator works, thank you. On my computer the difference saves roughly 1.3ns per increment or 13µs for a 10_000 iteration loop. Consistency of the tests trumps this tiny bit of increase in performance. Optimizing this should happen on the Opcache level, not the programmer level.

[iluuu1994]

do you really want PHP to waste time creating 9 copies of $i, just to immediately discard the copies? why would you want that?

Both pre- and post-inc create "copies", in that the value is copied to EX_VAR(opline->result.var). The only difference is whether it's done pre- or post-operation. The actual reason why pre-inc is faster is because it has a SPEC(RETVAL) specialization. The same could be added to post-inc, but probably wasn't with the assumption that it's less common for the return value to not be used. Not creating additional specializations reduces binary size and potentially improves cache locality. I'm not sure this assumption is correct though.