Back in the day some forty years ago when learning FØRTRAN, we were admonished, in the name of tight code, to set the test condition in a DØ loop to a previously-established variable in lieu of an expression in order to avoid wasted repeated computing time each time the loop incremented.
Does the same apply to AppleScript’s Repeat loops?
For example, would this:
set testCondition to "testResult"
repeat with i from 1 to largeNumber
--
repeat until x = testCondition
--
end repeat
end repeat
…be better (strictly speaking less CPU-intensive) than this?:
repeat with i from 1 to largeNumber
--
repeat until x = "testResult"
--
end repeat
end repeat
They told us that in FØRTRAN it would save resources because the overhead of assigning the internal variable for the test condition from the string each time was greater than having had the string variable already pre-established. It may not seem like much, but if so, even with today’s fast CPUs it would add up for long loops, no?
AppleScript: 2.0.1
Browser: Firefox 4.0.1
Operating System: Mac OS X (10.5)
The last time I tested this with speed trials ” a few years ago now ” it was the same in AppleScript. Storing a value in a variable and using the variable many times was faster than using the literal value many times. I think it’s because with a variable, you have the same instance of the value every time, whereas the script creates a new instance every time it runs code containing the literal value.
However, the difference is very small. You’re more likely to be offered the “variable” idea as a speed tip by someone who happens to know it than to be frowned upon for bad practice.
I also think the loop becomes a little tighter, if you can precompute the number of times it is to execute up front, and then use the repeat x times construct, then your loop doesn’t test for superfluous conditions, as it iterates.
Not like fortran, fortran would do something that is is not possible in AppleScirpt (because of the language it’s written in). Comparisons are continuously made in AppleScript while fortran can cleverly keep values in the processor’s register to keep performance up. This processor code optimization totally depended on how someone wrote their code. In a modern day computer the code will lose from several cycles up to 90 cycles (virtual memory not included) to read memory. Fortran used the registers of the processor to keep this latency to a minimum.
Then on the other hand, fortran is so low level while AppleScript is one of the highest level langauges. The code comparison is surrounded by hundreds up till thousands of instructions for dynamic type checking etc… That means even if there was a difference, the actual difference would be less than 0.01% in real performance.
But it’s not that weird question. I program more than AppleScript only and what fortran does automatically and very clever I need to be do by hand in C. If you want to take a look under the hood of AppleScript you’re probably sorry to hear that the AppleScript interpreter is never been opened. However, according to the creators, AppleScirpt is completely based on hypertalk/hypercard which is open. AppleScript’s architecture is still based on stack and cards.
This is a brief on Apple Script (found at Daring Fireball) and its messaging model. I always thought it was modeled after Small Talk’s messaging model, I realize that doesn’t exclude hypercard and stacks being used as the pattern for an architecture.