See also the topic Subroutines.
The overhead of calling an internal subroutine is very small. This is because all parameter passing is via global variables. For a small subroutine that is used in more than one program, consider using the INCLUDE statement to add it to the main program as an internal subroutine.
Note: Because all identifiers used in a module are global in scope, you will need to be careful that internal subroutines included in this way do not use the same identifiers as the programs that call them.
An external subroutine is started in a similar way to a cataloged DataBasic program and therefore has the same performance overheads. However, the memory structures required by each user to run the subroutine are cached, and these overheads are therefore only incurred the first time each user calls the subroutine. Subsequent calls use the copy in the cache. The size of the cache has been chosen to balance program efficiency and overall system performance; it favours the use of a small number of frequently called subroutines. If your application uses a large number of external subroutines, a larger cache might make it more efficient; contact Northgate for advice.
The following points should be considered when using an external subroutine when performance is or may be a problem:
Avoid opening files in an external subroutine as, unless the file variable is passed back to the calling programs, this will result in the file being closed on exit from the subroutine (see topic File Open And Close). Create your file variables in COMMON and use the COMMON variables to access the opened files from within your subroutines.
Note: If you create your file variables in a named COMMON section, your program must close the files concerned on exit. If this is not done, the files will remain open until the user logs off.