>>Using m.var *is* faster than var by itself. I don't recall why, but it has something to do with losing cycles trying to figure out if var = memvar, fields, whoozit, whatzit, et al.
>
>Right, it saves passes through the nametable.

Yes, that's what we are told it is supposed to do, but it doesn't seem to. It seems that the only way to prevent "passes through the nametable" is to have no table open or to have no table selected by using SELECT 0.

Curiously I found that VFP7 ran faster with NO "m." at all on either side of an assignment than with "m."s present on both sides, even when a 95-field table was active/selected. I found that it (and VFP6) ran slowest when BOTH sides of an assignment have a "m." whether a table is selected or not.
What seemed really strange, though, was that VFP7 took a full second longer than VFP6 when the "m." was only on the LEFT side of an assignment when a table was active/selected. When an assignment had a "m." only on the RIGHT side then the VFP7 and VFP6 times were virtually the same when a table was active/selected and virtually equal to running with NO "m." at all.

My admittedly informal tests only had 2 assignments within a FOR loop of 1 million iterations. The numbers are at the office but they approximated (95 field file active/selected):
UPDATE: now back at the office, so here are more accurate numbers observed...

test kind      VFP6   VFP7
               (sec)  (sec)
no "m."         1.7    2.6
"m." left only  1.8    2.6
"m." right only 1.5    1.5
"m." in both    3.4    3.1