AFP 3.0 has been designed with operational performance as a top priority. Instead of conducting a time-consuming investigation at each invocation to determine which application a page belongs to and whether or not certain events are present, this check is done only once during compilation. During compilation AFP rounds up all data pertaining to the same .afp page. This includes the .code file, the .afpa file, the .afpa.code file, .config files, if applicable, plus all files included through *!<[INCLUDE: "..."]>. Of all these files the compiler will generate a single .prg file.

This FoxPro program file includes all individual elements. HTML code is converted to FoxPro code which causes the HTML content to be added to the output buffer. To this end AFP employs an optimized variant of Response.Write(). The entire code in the file .afp will be checked for particularities like the command ?, and will then be converted to the corresponding FoxPro code. Procedures, functions and class definitions are extracted from the .code files and added to the .prg file generated by the compiler. Events defined by the AFP, e.g. Event_PageCallBefore, are inserted at precisely defined locations.

The result is a .prg file that will fill the output buffer during execution. This .prg file contains everything that AFP needs to know to execute a page. Access to the original page is only made to determine if pages have been changed or even deleted.

During the saving process in the cache directory, the name is determined on the basis of the requested Web address by removing inadmissible characters and adding a checksum to the file name. This makes for very long files names but lets you determine the name of the file in the cache from the address entered by the user. No longer will you need to search a single, error-prone table like Repository.dbf or save of the generated programs in publicly accessible Web directories where they are susceptible to outside attacks and where the allocation of user privileges does not always permit this.

The file name includes not only the complete path but also the host name used. Occasionally, files can be reached via multiple host names. Thus, most Web servers can be addressed through a public name, an internal name, the name localhost, the public IP address and the internal IP address. For each of these names separate files are created in the cache.

Visual FoxPro blocks .fxp while executing them and subsequently deposits them in a memory cache. Later requests will execute the version in the memory. AFP employs a versioning system to forestall access errors in cases where one AFP instance executes a page while another instance attempts to compile it and would thus give modifications to the .afp file instant effect.

Additional to the root name of the URL entered a unique string based on a GUID is added to each page. The .version file notes which version is current. The benefit of this variant lies in the fact that modifications to the .afp can be taken into account instantly. There is no time-consuming wait for the complete unloading of all instances of a page.

Increased space requirement in the cache directory and a rising number of files in this directory are the downside aspect. Files in the cache can be deleted any time without risk. AFP 3.0 will inhibit the deletion of all files that are still required. All other files will be newly generated whenever required. To be able to use the cache directory with the maximum efficiency you should deposit it on a hard disk in NTFS or a similar file system. FAT file systems containing a great number of files suffer from a substantial loss of speed. Even though AFP 3.0 may behave strangely – deleting all files in the cache is a solution that frequently works.