>Hilmar,
>
>>Update: I left the program running; using VFP 6, the program crashed at i = 64350, i.e., that many properties were added. Pressumably, a few of the built-in properties summed up to a round number (like 2^16, or 2^16-1).
>
>AFAIR that is a NTI border line, the same as in the "normal" variable space of vfp, which is reflected in every object again.
>>
>>But things got very slow, a long time before the program crashed.
>
>I think the slowness is at least partially the fault of the version[vfp6] - there were quite a few different runtime characteristic changes between vfp6 and vfp8 (I skipped vfp7). Parts of this is described in Calvin Hsia's blog.
>
>Regards
>
>thomas

Thomas,

Calvin has spoken of the allocation of objects, not of the properties.
Two issues are resolved not:
- the deallocation of the objects has been slow
- the properties are allocate as an array where a sequential search is made.

Another point is relative to the baseclass's properties,
these have put at the end of the search,
then to read "Top" in a native object is very more express
respect to read "Top" in an object with 100 properties added.

The read/write of properties is the speed heel of achille of VFP.