Esparta,

Well, knowing what I know about mathematical instructon performance, flipping the sign bit is faster than adding/subtracting which is faster than multipying/dividing, so I'd expect a benchmark to perform in this order for the first three test loops:

?

lnBaseTime = seconds()

for i = 1 to 1000000
endfor

lnBaseTime = seconds() - lnBaseTime

j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   j = -j
endfor

? seconds() - lnSeconds - lnBaseTime, "negate"

j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   j = 0 - j
endfor

? seconds() - lnSeconds - lnBaseTime, "add/subtract"


j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   j = j * -1
endfor

? seconds() - lnSeconds - lnBaseTime, "multiply/divide"


j = 10000000
lnSeconds = seconds()

for i = 1 to 1000000
   j = -j
endfor

? seconds() - lnSeconds - lnBaseTime, "negate with another value"


lnSeconds = seconds()

for i = 1 to 1000000
   j = -i
endfor

? seconds() - lnSeconds - lnBaseTime, "negate with another memvar"

lnSeconds = seconds()

for i = 1 to 1000000
   j = -1
endfor

? seconds() - lnSeconds - lnBaseTime, "test constant assignment"

and the theory holds, negate is 15% faster than add/subtract which is 4% faster than multiply/divide.

There's also a couple of other things to note. 1) you have to make sure you are really timing what you think you are timing. lnBaseTime corrects out the amount of time that the base looping takes. You all were correct in that the time to make the calls to rand() were consuming a large portion of the time. 2) test some other boundary conditions like constants, other memvars just to see if there's some huge variation. 3) run the benchmark several times until you get repeatable consistent average results.

You guys bring up store is faster than =, which suprises me a little, I mean heck there's 25% more tokens in a store command than an = so it should be slower, but it's not:

j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   store -j to j
endfor

? seconds() - lnSeconds - lnBaseTime, "store negate"

j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   store 0 - j to j
endfor

? seconds() - lnSeconds - lnBaseTime, "store add/subtract"


j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   store j * -1 to j
endfor

? seconds() - lnSeconds - lnBaseTime, "store multiply/divide"

but the difference is 0.08 seconds on a million iterations (P4m 2.5ghz), I think I'll stick with with the less COBOLly = *g*

The proverbial m. always comes up too...

j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   j = -m.j
endfor

? seconds() - lnSeconds - lnBaseTime, "m. negate"

j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   j = 0 - m.j
endfor

? seconds() - lnSeconds - lnBaseTime, "m. add/subtract"


j = 1
lnSeconds = seconds()

for i = 1 to 1000000
   j = m.j * -1
endfor

? seconds() - lnSeconds - lnBaseTime, "m. multiply/divide"

a difference of 0.01 seconds on a million iterations, again I'll stick with the more readable m-dotless version. This is affected too by currently open work areas, this test was done with no tables open. Bottomline, never take anyone's benchmarks for the Gospel truth, verify them for yourselves and weigh them according to your own situation.

>Same to me, may be its time to change to the new old-fashioned stuffs. It would be interesting to see what David F. say about it (he's the king of speed testing to me)
>
>>you are welcome <s>
>
>>what is interesting to me is, that the old 'store' command is faster then the '='. i never us 'store' because i don't like the redability in the code. i think it's easier to read/follow the code if '=' is used.
>
>>>That's correct, it seems like a delay with RAND() function. Thank's for the Heads Up :-)