>>>>> Also include m. at least for performance issue in VFP7 :
>>>>
>>>>Hi Cetin,
>>>>Can you tell me what sort of performance issue is involved with the "m."?
>>>>
>>>>Thanks
>>>
>>>If you don't include m. in for loops VFP7 is slower than previous versions (documented somewhere).
>>>Cetin
>>
>>Hi Cetin,
>>
>>
>>I started another thread 647967to ask more about this, and people over there seem to say that using the m. is slower (someone even said 1/3). But Craig ran a test that seemed to indicate that using the m. in a for loop was negligently slower.
>>Now I'm really interested in this subject.
>
>Bill,
>I'm the liar of docs :) I didn't run any tests (and even can't think of a good test that could say clearly say this is true or false). I read the fine prints more than other parts and I clearly remember this was somewhere in docs, maybe KB. Unfortunately I can't locate it once more. Personally blindly thinking it's true as I remember it was coming from fox team with a test showing the case. Till I can prove wrong myself I believe it (personally:)
>Cetin

Bill,
Just saw your long thread about it :) and some tests. I also just made a simple test and using m. was faster -as I expected- :) You see it's easy to create a test that shows something is true and yet another to show it's false :

CLOSE all
USE customer
lnStart = SECONDS()
FOR m.ix=1 TO 5000000
 m.dummy = m.ix
ENDFOR
? SECONDS()-lnStart

Try with removing different m. If you remove m. from left side it'd speed up but still faster than the case w/o m.
But as said before it should be something else to be documented somewhere (otherwise I could ignore 25% speed when negligible over 1 million loops)
Cetin