Very fast Revolution commands and functions?

Alex Tweedly alex at
Tue Feb 8 18:30:48 EST 2005

Ken Ray wrote:

>On 2/8/05 1:31 PM, "Lynch, Jonathan" <BNZ2 at CDC.GOV> wrote:
>>Is switch faster than if-then?
>>Is add 1 to X faster than put X+1 into X?
>Jonathan, you should read up on the Scripting Tricks called "Increasing
>Script Performance" by Wil Djikstra that I have posted on my site... they go
>into this and more:
Thanks !  I had somehow missed those ....

I've sent a private reply on a few topics from there, but a general 
interest one is (from Part 3)

> You most likely know that
>     |add 1 to x|
> executes faster then:
>     |put x + 1 into x|
> The reason is that in 'add 1 to x', the variable x is accessed only 
> once, whereas in 'put x + 1 into x' it is accessed two times. The 
> computer doesn't know that the result of 'x + 1' should be put in the 
> same place x and has to figure out twice where in memory x resides; 
> execution of the statement is similar to the execution of 'put x + 1 
> into y'.

If you have a long enough memory, you may remember seeing similar advice 
about writing C (or Pascal, or ....)

You don't any more, because any reasonable compiler will optimize this 
out; since there is no way for the meaning of "x" to change within the 
statement  "put x+1 into x", there is no need to "figure out twice where 
in memory x resides".

Similarly, given (the equivalent of) a couple of statements like
  put x+6 into y
  put x+7 into z
or more significantly
  put a[5]+6 into y
  put a[5]+7 into z
any decent C compiler will (unless told not to by compile options, and 
assuming that y,x are simple variables) optimize the calculation, and 
probably also the register load, of the memory location for a[5].

Is there any reason why MC/Rev can't do a similar flow analysis and 
therefore eliminate double look-ups for x ?

Alex Tweedly

-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 07/02/2005

More information about the Use-livecode mailing list