>Hi Fabio,
>
>>You can reduce the problem with
arrays of Members,
>>but it is a VFP behaviour, and I doubt that you can go around it.
>I haven't tested:
>are you saying that the destruction will be *markedly*
>faster if you don't form.addObject into 1000 form control references
>but instead createobject() into a form.myAddedButtons[1000]
>and releasing them manually with form.myAddedButtons = .f. ?
>
>Or have I misunderstood your answer ?
>
>regards
>
>thomas
Hi Thomas, you have understood well.
With great approximation:
AddScalarMember_Time=VFPImplementationC++Code(NObjects,ObjectClassComplexity,CPUCacheSize)
is ~ 2xNObjects => 3xTime within Cache
but when you go out of cache, you have a big slowing down and this ratio change.
AddArraysMember_Time=AddScalarMember_Time / 2
it is 2x 4x faster,and the Cache to Memory transition start with 4x NObjects
- CUSTOM Combo
- NObjects AddScalarMember AddArraysMember AddScalarMember
- 500 30ms 20ms 351ms
- 1000 101ms 50ms 1011ms
- 2000 341ms 150ms 3264ms
- 4000 1832ms !!!!! 490ms
- 8000 11476ms out 1813ms
- 16000 6619ms !!!
- 32000 51243ms out
DestroyScalarMembers_Time = 3 x AddScalarMember_Time
DestroyArraysMembers_Time = DestroyScalarMembers_Time / 4
If you test VFP, you can found that:
- normally, VFP implement C++ loops for do one operation ( the faster choice for little elements),
and a lot very rarely uses algorithms of preventive analysis of the future code executed
(something exists for the FOR/ENDFOR and other cycles) that it will come executed subsequently, and therefore results to you are necessarily these.
Honestly, to optimize VFP is not simple,
because every optimization uses some invariant rule, and with:
AddObject
RemoveObject
AddProperty
RemoveProperty
EVAL()
&Macro
COMPILE
RELEASE
it is not easy to find of the effective rules.
Many possibilities are, but it is the VFPT that decides.
Fabio
