Your test shows that the difference is negligible and not worth making code less readable.

>Hi Bill
>
>This is one of my pet topics ;). I believe its important to really understand the code we write.
>
>m. Rule: If when checking variable contents and there is a field that matches the variables name in the current alias, m. tells VFP to look for the memory variable instead of the field name.
>
>Look at these lines of code...
>
>lcVar1 = 1
>store 1 to lcVar
>m.lcVar1 = 1
>store 1 to m.lcVar
>lcVar2 = m.lcVar1
>if m.lcVar1 = m.lcVar2
> ?"Hello"
>endif
>
>Line 1 is clearly a variable assignment. The m. is not necessary.
>Line 2 is clearly a variable assignment. The m. is not necessary.
>Line 3 is perhaps easier to read, but the m. is redundant.
>Line 4 is also easy to read, but redundant.
>Line 5 is best written this way. Its perfect according to the above rule.
>Line 6 is also best written this way, for the same reason as Line 5. Memory variables are being checked (not assigned) on both sides of the equal sign.
>
>I wish VFP would give a syntax error on Lines 3 and 4. Then, everyone would know about this issue.
>
>Hungarian notation proponents will argue its unlikely that a field name will match the variable name, but the point is, if it should ever happen, the code will break! Imagine how long it'll take to debug. That'd be learning about this the hard way eh? I explained this to an associate just recently, and he didn't know it. He hadn't been bitten by it, but that's just luck.
>
>BTW, should a programmer inherit your code and add a field to a table, breaking the code, you'll be blamed <g>.
>
>As for performance I just ran this...
>
>a=SECONDS()
>FOR lnI = 1 TO 500000
> a1 = 1
>ENDFOR
>?SECONDS()-a
>
>resulted in .360 seconds
>
>a=SECONDS()
>FOR lnI = 1 TO 500000
> m.a1 = 1
>ENDFOR
>?SECONDS()-a
>
>resulted in .362 seconds
>
>VFP7 with a P3650
>
>
>>I just saw a message on another thread (message id 646222) that made reference to using m. for performance issues in VFP7.
>>
>>What's that all about?
>>
>>TIA