Visual FoxPro is designed to be the fastest relational database development system. Applications you create with Visual FoxPro can have widely varying requirements and purposes. Because of this variety, you might want to optimize the operating system, Visual FoxPro, or your application for maximum performance.
This chapter describes the ways you can optimize Windows and Visual FoxPro for your own use. For more information on optimizing applications you create in Visual FoxPro, see Chapter 15, Optimizing Applications, in the Programmer’s Guide.
This chapter discusses:
An effective way to optimize Visual FoxPro performance is to get the best use of your computer’s hardware and environment. This section addresses how to use memory effectively and how to get the best performance from your hard disk.
The most effective way to optimize your system for Visual FoxPro is to provide it with as much memory as possible. Visual FoxPro can take advantage of enormous amounts of computer memory. As well as providing memory, you can optimize the performance of Visual FoxPro by closing all other running applications on your computer.
To get the best use of your computer’s memory while running Visual FoxPro, follow these guidelines:
To increase the number of applications that you can run simultaneously, Microsoft Windows supports virtual memory by swapping segments of code (code that is the least recently used) from RAM to the hard disk in the form of a swap file. As a rule, the default settings in the Windows operating system for managing virtual memory meet the requirements of most users; these settings are recommended.
Note The swap file does not improve Visual FoxPro performance and is not a substitute for more RAM. If you do need a swap file, make sure you create a permanent swap file rather than a temporary swap file.
You can free memory for Visual FoxPro by simplifying the way windows and screen backgrounds are displayed.
By managing your hard drive, you can improve overall product speed. Follow these guidelines for getting the best performance from your hard disk:
Disk input/output performance degrades significantly when a disk drive is nearly full. If your disk drive has little free space, you can increase Visual FoxPro performance by removing unnecessary data or by purchasing a larger capacity drive. The more free disk space available, the more likely it is that contiguous blocks of disk space are available. Visual FoxPro uses this space for changes and additions to database, table, index, memo, and temporary files. Increasing free disk space therefore improves the performance of any commands that change or add to your files. More disk space also decreases the time required to read those files in response to your queries.
The way that Windows and Visual FoxPro manage files on disk can greatly affect the performance of your application. This section explains how to:
As a directory becomes increasingly congested with entries, the operating system takes longer to find files. How fast your system can search its directories is a function that is not under the control of Visual FoxPro.
To correct this situation, you must reduce the number of files in your directories. To reduce the number of files in your directories and speed up file search times, try the following:
This process decreases the number of files in your application’s subdirectories, thereby increasing performance.
Deleting files from a directory does not immediately speed directory searching. When a file is deleted, the entry remains as a “hole” in the directory and is still included in directory searches.
Visual FoxPro creates temporary files for a variety of activities. For example, Visual FoxPro creates temporary files during editing, indexing, and sorting. Text editor sessions can also create a complete temporary copy of the file being edited.
By default, Visual FoxPro creates its temporary files in the same directory that Windows stores its temporary files, unless you specifically designate an alternate location. Specify an alternate location by including one or more of the EDITWORK, SORTWORK, PROGWORK, and TMPFILES statements in the Config.fpw file.
To specify the location of temporary files
In most cases, you should specify one location for all Visual FoxPro temporary files. However, always make sure that the location you specify has enough space for all possible temporary files.
The directory of temporary files should contain as few files as possible. A low number of files reduces the amount of time Visual FoxPro waits for Windows to return file handles.
If you have a large amount of RAM (more than 16MB), you can consider using some it for a RAM drive and locating temporary files on it. However, in general, the more RAM is available, the better Visual FoxPro (and other Windows applications) run, and reserving RAM for a RAM disk can affect performance adversely. If you do want to try using a RAM disk for temporary files, you should probably not specify the RAM disk in the location for the SORTWORK statement, because temporary files created during sorting can be extremely large.
For more information on temporary files, see Optimizing Visual FoxPro in a Multiuser Environment later in this chapter.
Though Visual FoxPro is always fast, you can optimize the startup and operating speed. This section describes enhancing Visual FoxPro performance by managing startup speed and optimizing SET commands.
The time required to load and start Visual FoxPro relates to the physical size of Visual FoxPro, the length of the PATH statement in effect, the number of items to be found at startup, and other factors. You can control the load size, the search path, component file locations, and the startup SET command values of Visual FoxPro.
Visual FoxPro seeks Foxuser.dbf and Config.fpw in the following places:
For instance, you might start a Visual FoxPro application by using a command line such as the following:
VFP MYAPP.APP
– Or –
VFP MYAPP.EXE
If the startup application or executable file contains a Config.fpw file, it is always used and cannot be overridden.
You can also speed startup by preventing Visual FoxPro from loading files you don’t plan to use. If your application does not use the FOXUSER or FOXHELP file, disable them in the Config.fpw file by using the following commands:
RESOURCE = OFF
HELP = OFF
Visual FoxPro seeks all other Visual FoxPro components (GENXTAB, CONVERT, and so on) only in the Visual FoxPro directory. If you place components elsewhere, you must explicitly identify the path to those components in your Config.fpw file. For example, you might specify these locations:
_TRANSPORT = c:\migrate\transport.prg
_GENXTAB = c:\crosstab\genxtab.prg
_CONVERT = c:\fp2vfp\convert.app
You can use the environment variable FOXPROWCFG to explicitly specify the location of Config.fpw. For details about the FOXPROWCFG variable, see Chapter 3, Configuring Visual FoxPro.
If you don’t plan on using any of the Visual FoxPro components listed previously, set them to an empty string to speed startup.
To optimize the load size of Visual FoxPro
cFileVariable = ""
Replace cFileVariable with _TRANSPORT, _CONVERT, or other variables as appropriate.
You can optimize the operation of Visual FoxPro by tuning the values of certain SET commands.
The following table shows SET commands that have the greatest effect on performance, and their settings for maximum performance. You can specify SET command values by including them in the Config.fpw file, by typing them in the Command window, or by setting them in the Options dialog box.
Command Settings for Maximum Performance
| SET Command | Performance Setting |
| SET ESCAPE | ON |
| SET OPTIMIZE | ON |
| SET REFRESH | 0,0 |
| SET SYSMENU | DEFAULT |
| SET TALK | OFF |
| SET VIEW | OFF |
When you run Visual FoxPro in a multiuser environment, you can improve performance by handling temporary files effectively and by controlling the way files are shared.
In most multiuser environments, you should place temporary files on the local drive. How you manage the files depends on the amount of disk space and RAM on the networked computers that run your application.
If networked computers have sizable hard drives with plenty of free space, you can improve performance in a multiuser environment by placing Visual FoxPro temporary work files on local drives. Redirecting a file to a local drive provides additional speed by reducing the need to access the network drive and, therefore, reducing the amount of network traffic.
On small networks, with older networked computers and slow hard drives, you might experience better performance by leaving Visual FoxPro temporary files on the file server. When in doubt, direct temporary files to the local hard drive. When working on large, heavily used networks, always redirect temporary files to the local hard drive.
For example, to redirect all temporary files to a directory called WORK on drive C:, include the following lines in your Config.fpw file:
TMPFILES=c:\work
EDITWORK=c:\work
SORTWORK=c:\work
PROGWORK=c:\work
The SORTWORK directory must be large enough to hold the temporary files that Visual FoxPro generates during sorting and indexing activities. When Visual FoxPro handles large tables, these temporary files can be very large.
By placing all your temporary files in a single directory on a local drive, you can safely erase the contents of the temporary file directory before each Visual FoxPro session. This will purge your system of any temporary files that were created but not erased by Visual FoxPro due to a system reboot or power loss.
If users are sharing tables on a network, the way you manage access to files through file and record locks can affect performance. You can enhance performance by using the EXCLUSIVE clause of the USE and OPEN commands.
With sharing enabled and EXCLUSIVE set to OFF, tables on a shared drive are opened for multiuser access. In this situation, the following command opens CUSTOMER.DBF in shared mode:
USE c:\customer.dbf
Visual FoxPro can buffer write operations to non-shared files, thereby increasing performance. To increase performance of APPEND, REPLACE, and DELETE commands, be sure to open local tables or databases using the EXCLUSIVE clause of the USE or OPEN commands, as in the following example:
OPEN DATABASE mycompany EXCLUSIVE
USE c:\customer.dbf EXCLUSIVE
Avoid opening and closing tables repeatedly.
For more information on accessing files in a shared environment, see Chapter 17, Programming for Shared Access, in the Programmer’s Guide.