>Fabio,
>
>Thanks for your explanation. Yes I agree there probably is something in referencing the workareas that is not as optimized as could be.
>
>Should we pass this to calvin hsia ??
>
>Walter,
>

If this is possible and if Calvin has a opened mind then the answer is yes;
however i think ( or i hope ) Calvin known this issue.

Fabio

>
>>>Fabio,
>>>
>>>>I'm sure that this not degradation
>>>>can to be obtained for the objects.properties and tables.fields too.
>>>
>>>Can you explain (I'm afraid I don't understand).
>>>
>>>Walter,
>>
>>Walter, I have made all the verifications much time makes and in many situations.
>>
>>Now, m.xxxxx is a list of variables,
>> like object.properties
>> datasession.tables
>> tables.fields.
>>
>> On current VFP all can be created or be destroyed
>>(except the property of the classes),
>> and all the dynamic code can be generated that it wants.
>>
>>The variable ones do not suffer from this problem, but they have a limit: MVCOUNT.
>>Therefore the variable ones are allotted all to the beginning
>>
>>I guess this:
>>When a variable is created, it is placed in the M. array into a specific row ( like a pointer ),
>>and VFP can optimize a multiple access within a module ( it search the pointer 1 time only )
>>
>>If VFPT implement this for the other lists ( properties,tables,fields),
>>a loop can to become independent from the list count , otherwise not is hope.
>>
>>Form variables, on help:
>>
>>Note:
>>The number of bytes used represents memory used by character type variables. Character type variables are the only type of variables that require additional memory beyond that allocated by the variable count specified with the MVCOUNT configuration item.
>>
>>
>>Fabio