Hi Fabio,
>>What the point of such optimization?
>This require a backtracking compiler, or a 2 pass compiler.
Technically you are correct. But I think Sergey meant, that in real life
this missing optimization is never hurting.
As we both know, a good optimizing compiler will optimize
all of the loops away at run time - but even for vfp the examples
exaggerate the possible gains in real life.
If you include
very basic "functionality" into the example,
the percentage of the gain drops enormously. Yes, there are some use cases
where a case construct is used to filter without a following instruction,
but they are not the norm - and if performance is an issue,
these are probably handled in a global if surrounding the case. Consider:
CLEAR
T0=SECONDS()
#define endloop 1000000
PUBLIC n_even, n_odd
FOR K=1 TO endloop
NEXT
T00=SECONDS()-T0
T0=SECONDS()
FOR K=1 TO endloop
IF MOD(k,2)=1
n_odd = k
ELSE
n_even = k
ENDIF
NEXT
T11=SECONDS()
FOR K=1 TO endloop
IF MOD(k,2)=1
n_odd = k
LOOP
ELSE
n_even = k
LOOP
ENDIF
NEXT
T12=SECONDS()
FOR K=1 TO endloop
DO CASE
CASE MOD(k,2)=1
n_odd = k
OTHERWISE
n_even = k
ENDCASE
NEXT
T23=SECONDS()
FOR K=1 TO endloop
DO CASE
CASE MOD(k,2)=1
n_odd = k
LOOP
OTHERWISE
n_even = k
LOOP
ENDCASE
NEXT
T24=SECONDS()
? "empty" ,T00
? "IF " ,T11-T0-T00 AT 10 ,T12-T11-T00
?? TRANSFORM(((T11-T0-T00) /(T12-T11-T00)-1)*100 ,"@R LOOP SPEED GAIN 99 %") AT 50
? "CASES " ,T23-T12-T00 AT 10 ,T24-T23-T00
?? TRANSFORM(((T23-T12-T00)/(T24-T23-T00)-1)*100 ,"@R LOOP SPEED GAIN 99 %") AT 50
Puts the gain down a lot, and if you have more instructions...
If I have a recurring loop taking considerable amounts of runtime,
I can optimize this loop (as we both probably do) with "loop".
But even the time spent optimizing the speed of calling UDF / methods
with a few parameters would probably better for the speed of the whole app.
I think such an optimization would be a non-optimal use of the resources of the VFPT -
other optimizations could make a greater difference to the "usual" app.
regards
thomas