2007-10Oct-06

Accumulating the slow parts

As a developer you need a fast machine and fast access to keep the duration of the typical edit-compile-run cycle at a minumum. Slow machines have direct impact on development times. Having a fast machine has a major drawback though: You don't get a feeling what your application feels like to a real user that doesn't work with local data on a fast machine.

Monitoring tools like FILEMON or Ethereal give you a first overview of the amount of data that your application transfers across the network in a particular situation. After optimizing the application to reduce bandwidth usage you might still be surprised.

Many statements in Visual FoxPro, especially SQL SELECT statements, cache heavily. Cached contents expires after a timeout period of five seconds, by default. You can control the time with SET REFRESH and the "Refresh" setting of CURSORSETPROP.

You might get nasty surprises if your code consists of a series of SELECT statements that access the same table. On your machine all these statements execute in less than five seconds. Consequently, only the first SELECT statement actually reads from the table. All subsequent SELECT statements access the cache. On real client machines, though, SELECT statements easily run for more than five seconds. VFP invalidates the cache right after terminating the first query. The next queries force VFP to read the entire table over and over again.

Instead of transferring like 60 MB in a two seconds for ten queries on your local machine, you might end up transferring 600 MB in a over a minute across the network... just because every single query runs for more than five seconds.