Hi, Jim!

Indeed, this is a good fix and I will try to explain why.

I remember, there were discussions in the past about this at the ProFox mailing list, and seems everybody agreed that it was strange that variable accessing with m. in VFP6 works sower than without m.

Despite hungarian notation, there still could be collisions between variable names and field names in the current work area. Compare following variable and field names:

lcAreaLine variable - lCarEALine field
lnArrow variable - lNarrow field
liNetINY variable - LineTiny field
liStandardOrWeird - ListAndArdorWeird

etc etc.

There could be really a LOT of collisions and hungarian notation is not a complete approach to avoid collisions, specially, when writing wide-use VFP classes and frameworks. As a result, in most cases it is required to use "m." before all variables (here we use this as a corporate coding standard).

In VFP6 m. worked much slower than without it, for no reason really - it looked like VFP compiled p-Code used different codes for variable access with m. and without m., and with m. that code was processed with less priority, that caused slow down.

In VFP7 seems slow down without m. is because VFP7 need to determine if name used for accessing value is variable or current table field. As a result, the more field in the current table, more is delay. I'm not sure if this delay could be avoided, though most likely not (I know C++ well too ;). Anyway, is this really a bug? I do not think so, and the fact that finally m. variables work as supposed (more quickly) is very good thing, indeed, because most used arts of applicationcode are usually generic subroutines and classes, where m. is used by nature - to avoid collisions with field names in current alias. In addition, slow down for without m. in VFP7 is far less than slow down in VFP6 for m.

So far so good.

>>Ken
>>
>>Reputable people report that use of m. nomenclature on the right side of variable assignment is far faster in VFP7 than m.-less syntax.
>>
>>I.e.
>>
>>

>>myvar=m.lcMyOtherVar
>>

>>
>>is much faster than
>>
>>

>>myvar=lcMyOtherVar
>>

>>
>>The difference is not that using m. is now faster; the difference is that NOT using m. is much slower than it used to be with VFP6.
>>
>>Those of us who deliberately changed to hungarian notation seem to be disadvantaged.
>>
>>Why has this happened? Is there a new feature/benefit that causes this as a side effect?
>>
>>Regards
>>
>>JR
>
>I tested Cetin's code, and there is indeed a difference from VFP6 to VFP7.
>
>The specifics of his example show the behavior at its most pronounced. Using his example, on my PC (PIII 933) the slowdown is ~.0000011 seconds per variable per iteration.
>
>I found that the slowdown is proportional to the number of fields in the table opened in the currently selected workarea. Since his code uses 255 fields, it represents the worst case; halving that number will roughly half the amount of the increase, and so forth down to 1 field. With 1 field, or no table open in the currently selected workarea, there is basically no slowdown, or it is negligible.
>
>To put this in perspective, on my machine you would have to reference variables around 909000 times, with the currently selected workarea containing 255 fields, to add one second to execution time. His example references 3 variables 5,000,000 times. Depending upon your application, hardware, etc., you may or may not perceive a noticable slowdown.
>
>I have entered this as a bug. At this point, I don't have an explanation for why this changed between VFP6 and VFP7.