LiveCode Forums.

This test handler came from another thread, comparing the relative speed between "if-then" and "switch. It was determined that "if-then" was a few percent faster. Now I find that running this gives very different results after several tries. Sometimes "if-then" is twice as fast, sometimes half as fast. Sometimes they are relatively equal, but at very different mutual speeds.

One has to have five minutes with nothing to do to even bother, but on a card with a two line field "x'" and this in a button script: After several runs I get things falling into four groups, typified by these examples:
"350/170"
"200/175"
"199/346"
"367/341"

All over the place, with 2:1 range. Do I just assume that other processes in the machine are using resources here and there that trip up the repeat portions of this handler, sometimes in the "if-then" section, and sometimes in the "switch" section? But the results are not scattered; they fall into just four ranges. So that does not sound like the reason.

Anyone else with lots of free time see this same small set of results?

Is there a way to lock out every process but LC, to the extent that such a thing can be done? Would it even out the handler? Would it speed up LC overall?

Craig

A minimalist test: gives much closer and far more consistent results, all runs around "57/51", in favor or "if/then".

So the inclusion of (identical) working code in the earlier handler causes the disparity between runs. Why should that be?

It is not surprising that the run times there are rather longer.

Craig

The first test uses different numbers in temp for the two sets of calculations. The second test does no calculations so the performance is more equal. Try removing the second value assignment in the first test so both loops are working with the same integer.

Just a guess but that's the main difference I see.

With 10,000,000 iterations, the takeaway I get from that test is that any speed difference is small enough to be almost immeasurable.

The course granularity of ticks doesn't help. Try milliseconds. It probably won't be much different, but at least you'll have a more precise understanding of just how little difference it makes.

Both if and switch are provided because they are best suited for different types of logic flows. Prioritizing code clarity is rarely a mistake.

If you have a specific real-world edge case where extremely small performance differences add up to a user impairment, let's look at the whole algo. As we've seen in many optimization threads here, the biggest differences often come from completely rethinking the problem being solved.

This came from:
http://forums.livecode.com/viewtopic.ph ... 34#p197834

@ Jacque. Now what do you know, it absolutely matters what numbers you work with. It never occurred to me that the randomness of the values I noticed might be related to the random function seed itself. In hindsight, it should have been obvious.

Ready? In either method, an even number runs twice as fast as an odd number. Why should it though, is a question. Does an even number pass through the "mod" function faster?

@ Richard. In the thread above, I recall we all agreed that the issue was mostly moot.

Craig

dunbarx wrote: ↑

Fri Nov 06, 2020 6:55 pm

This came from:
http://forums.livecode.com/viewtopic.ph ... 34#p197834
...
@ Richard. In the thread above, I recall we all agreed that the issue was mostly moot.

Yes, as far as switch vs if.

I still believe rethinking the problem to use arrays would cut the code size down tremendously, and there may also be a measurable speed boost.

9,000 cases is a lot to evaluate, when ultimately you're only looking for one. The hashing arrays use reduces search space by orders of magnitude over lists, almost a direct address reference.

I think this is just a case of curiosity, the same thing that makes people solve puzzles for no good reason. Craig (and I) fall prey to this affliction. I think it was Isaac Asimov who said, roughly paraphrased, that science doesn't advance when someone tries to solve a problem, but rather when they notice something and say, "well that's funny...".

Richard. For me, just an exercise.

Jacque. You and do go pretty far back, eh?

But what about the odd/even thing???

Craig

In the example case, if the number is even then the first MOD test evaluates to true. So the whole else condition is skipped.
If the number is odd, then the first test fails, so the else condition is evaluated as well. In this case, another MOD operation ultimately the same overhead as before. You wouldn't make a test like this in a real world scenario.
1. Check: Did this coin land heads up?
2. No? Better check it again then to see if it landed tails up.

(Might be argued that you can't be sure it's not a trick coin)

Jacque. You and do go pretty far back, eh?

Yup, but you look younger.

I think Sparkout nailed it.

Simple when someone else tells you.

Craig