>>Running a WinApp minimized but as the foreground task will likely run faster since only the virtual screen, and not the actual video memory, is being updated. I would not expect significant variations in performance in a normal vs maximized window.
>>
>>If you eliminate all or most screen I/O in batch operations, they will run faster, since writing to the screen takes measurable time.
>
>No, these are VFP 6 apps. I think your approach
>of running the apps minimized is interesting
>though. How do you think updating the status
>of the title bar
>(e.g. _Screen.Caption = TRANS( lnPercent) + "% done" )
>would compare to an @ SAY, therm bar or some such?
>

I don't have any benchmarks on it, so I couldn't really say. The mechanisms used to write a caption are the same ones used to write text to a location on the screen.

If you're looking to update things in a loop, you're incurring much the same penalty for writing something by updating the caption as updating a thermometer or writing to a screen location. if these are indeed batch operations that can take place asynchronously (without being overseen by an interactive user) I'd be inclined to create a simple job server and simply dispatch the batch operation to the job server and not waste cycles updating the screen at all. I doubt that the difference between 1,000,000 @...SAYs and 1,000,000 _Screen.Caption = operations would be significant, especially compared to 1,000,000 of either compared to none.

>Keep in mind that these are batch mode programs and
>will typically be processing 500K to 1M records?
>
> ...kt