I agree with all your observations, Al.

I'm surprised that the "observers" didn't take a more scientific approach to come up with a hypothesis as to what they observed; after all, a 250% performance increase would have deserved at least a white paper (and a claim to fame).

The only possible advantage I can imagine might be a "BROWSE" that is a bit more reponsive due to pre-fetching. Any other "tight" process would not benefit from asynchronous processing ... and that's what "I" consider when I'm talking "performance".

As I'm sure you're aware of, "performance" is often "perception".

I asked James to tell me what he "saw" that was so extraordinary, since all his observations seemed to be "visual".

I'm still waiting for a response.

>>>Actually, I didn't make the claim of performance increaes of 250 %, the book did. What I saw was a significant performance increase. It was enough to warrant using that solution because we did not have time to do a major rewrite and the company was not going to throw any more money into the network. The fact is the results were astounding, and I have yet to find a definative explanation for it, despite your excellent analysis.
>>
>>Maybe this will put it into perspective:
>>
>>Take the VFP EXE/Run-Time and strip out the IDE and all the GUI related commands/statements; what you wind up with is the "VFP ODBC Driver" (ie. a portable version of the VFP "data engine") with an ODBC API bolted on.
>>
>>The only difference between the VFP ODBC driver and the native VFP data engine is that the ODBC "might" be doing some extra bachground fetching.
>>
>>If the ODBC driver outperformed the "native" data engine it was a "fluke" and a review of the original code would have solved the problem (or simply rerunning the same set of samples a couple of times to allow for caching).
>
>I would tend to agree with you that the added overhead of an ODBC process/layer running on the same machine should, on balance, slow things down rather than speed them up.
>
>The ODBC driver runs as a separate process with its own memory space. In James' case the "native" app may be RAM-constrained via SYS(3050). In the ODBC case, the original app may be able to call on a non-constrained ODBC driver, effectively throwing more RAM at the entire problem.
>
>If the ODBC driver is not constrained it could indeed be pre-fetching more server data to local cache - in this case acting as a sort of local database server.
>
>Without knowing VFP low-level internals, I wonder if the lack of any UI support in the ODBC driver allows it to ignore any Windows events/polling and thereby increase performance. My understanding is that VFP isn't interrupted anyways in tight loops (like you might expect with data manipulation) so that might not make a lot of difference.
>
>One other intriguing possibility is having more than 1 CPU in the workstation. If the data access is synchronous (likely) it shouldn't make much difference - the app is going to wait for return of data either from the native engine on the same thread, or the ODBC driver on another thread. Asynchronous access could improve a lot, with the ability to hand it off to another CPU.
>
>It's interesting to speculate why James got the results he saw, but we'll need a lot more details on his configuration and testing before we can make sense of it.