>>>Just as a reminder: VFP 6.0 is still in beta. I personnaly don't pay any attention to speed issue when a software is still in beta.
>>>
>>
>>Yes it is, but I'm referring to running this under the Release Candidate, which is virtually identical to the product that will ship. There's no debugging code in that version. I guarantee that the final shipping product will have this performance issue also. I have a pending case open with Microsoft, and they have confirmed this.
>
>Doug,
>
>You are right, VFP6 is slower than VFP5 with your test. But my question is what real world situation does this test examine? I odn't forsee having 5 forms opne with 18 pages frames in each and programatically walking through each form and page.
>
>When I ran the test with more realistic values of 5 forms with 5 pages I got 1.63 for VFP6 and 1.17 for VFP5, not an earth shattering difference.

Although I certainly admit that this example is extreme in some ways, it does however mimick the behavior of our application that we currently have running at over 150 sites across the country. The number of forms is up to the user - they can open multiple instances of the form. The form in question does in fact have 18 pages in the pageframe, but we don't use the built-in horizontal tabs. We've got a class that we created that gives the appearance of vertical tabs along the left-hand side. And the number of controls per page also directly impacts the results of this test. Some of our pages have more, some have less, but 10-20 controls per page is probably average.

I don't think our users would find it acceptable if we put a hard limit on the number of forms they could open, nor would they find the performance slowdown acceptable. There is a real problem here that has to do with object instantiation and painting, something that was broken between VFP 5 and VFP 6. In fact, developers at Microsoft have already looked into the problem and confirmed that this problem was introduced while fixing a different bug.