TITLE:Back-to-Basics: FlashBASIC Performance

ISSUE:Multi-Value Solutions Dec'98

AUTHOR:Nathan Rector

COMPANY:Natec Systems

EMAIL:nater@northcoast.com

HTTP:www.northcoast.com/~nater/

FlashBASIC performance discusses three methods of increasing performance: replacing dynamic arrays with dimensioned arrays, replacing common with named common, saving screen images in a variable.

Replacing dynamic arrays with dimensioned arrays is especially effective when an item is read from a file, and manipulated extensively afterwards. If the number of attributes in the item is known, the "matread" statement may be used to read the dynamic string on disk into a dimensioned array. If the size is not known, or subject to change, read the item into a dynamic array, then use "dcount" to get the number of attributes, redimension a dimensioned array to the desired size, and assign the dynamic array to the dimensioned one. For example:

equ am to char(254)

read xx from "big.item"

size = dcount(xx,am)

dim stat(size)

stat = xx

Another great speed increase can be realized by using named commons to store data that must be used between various applications. See "common" for more information on this topic. If named commons are used for this purpose, all applications involved must be compiled EITHER with the interpreter or with FlashBASIC.

If an application does large amounts of screen output, it is suggested that screens be built as large strings at the beginning of the program. This way, a screen refresh is simply a "print" of a string variable.

x=@(-1):@(1,1):"Name:":@(1,2):"Number:":@(1,3):"Address:"

print x

To obtain the best possible run-time performance and compile-time, Pick Systems advises breaking up applications into many small modules. FlashBASIC removes the traditional run-time overhead of large numbers of call's and is able to create more efficient code when the modules are smaller. Furthermore, an application broken into several small modules takes considerably less time to compile than the same application stored in a single item.

The Pick/BASIC "@(x,y)" function speeds up from 10-20 times if the "term" definitions are compiled with the "o" option. For instance, if the current terminal is an IBM 3151 terminal, the "term ibm3151 (co" command compiles and produces FlashBASIC code for the terminal driver. This creates a hidden module for use with FlashBASIC code. For best results, use this feature with high baud rates and/or fast display devices.

Avoid user exits. Standard Pick/BASIC routines compiled with FlashBASIC will probably run just as fast, and possibly faster, than the same routines coded in virtual assembly.

Avoid disk I/O. If an application has read-only tables, it is best to read them all into memory at the beginning of the program rather than reading them piece-meal throughout execution. When reading an item, do a "matread" into a dimensioned array, rather than using several "readv's".

Choosing a FlashBASIC Level:

The "o" option may be followed by a number, from 1 to 9, which indicates the FlashBASIC (optimization) "level". If not specified, the level defaults to 1, which gives a large performance increase while minimizing compile time and object size. Higher levels increase object size by as much as 100% over that achieved with level 1, and increase compile time exponentially. Furthermore, levels above 1 yield relatively small performance increases for most applications. High levels also tend to use very large amounts of Unix or NT swap space. If the system runs out of swap space, FlashBASIC retries with a lower level. Line numbers (for error messages) and the state of variables within the debugger are also not guaranteed when using a level greater than one. Finally, the exact behavior of a specific level above one is undefined and may be different on different platforms or releases.

Pick Systems advises running routines with various levels to see if the run-time performance increase is worth the compile-time and object-size trade-offs. The best candidates for higher levels are small modules (less than about 200 lines) which have little or no string manipulation and lack significant amounts of screen or disk I/O. Using a level of 9 can cut in half such programs' run time as compared to their speed at level one, while not taking an unreasonably long time to compile.

TITLE:Back-to-Basics: FlashBASIC Performance

ISSUE:Multi-Value Solutions Dec'98

AUTHOR:Nathan Rector

COMPANY:Natec Systems

EMAIL:nater@northcoast.com

HTTP:www.northcoast.com/~nater/

FlashBASIC performance discusses three methods of increasing performance: replacing dynamic arrays with dimensioned arrays, replacing common with named common, saving screen images in a variable.

Replacing dynamic arrays with dimensioned arrays is especially effective when an item is read from a file, and manipulated extensively afterwards. If the number of attributes in the item is known, the "matread" statement may be used to read the dynamic string on disk into a dimensioned array. If the size is not known, or subject to change, read the item into a dynamic array, then use "dcount" to get the number of attributes, redimension a dimensioned array to the desired size, and assign the dynamic array to the dimensioned one. For example:

equ am to char(254)

read xx from "big.item"

size = dcount(xx,am)

dim stat(size)

stat = xx

Another great speed increase can be realized by using named commons to store data that must be used between various applications. See "common" for more information on this topic. If named commons are used for this purpose, all applications involved must be compiled EITHER with the interpreter or with FlashBASIC.

If an application does large amounts of screen output, it is suggested that screens be built as large strings at the beginning of the program. This way, a screen refresh is simply a "print" of a string variable.

x=@(-1):@(1,1):"Name:":@(1,2):"Number:":@(1,3):"Address:"

print x

To obtain the best possible run-time performance and compile-time, Pick Systems advises breaking up applications into many small modules. FlashBASIC removes the traditional run-time overhead of large numbers of call's and is able to create more efficient code when the modules are smaller. Furthermore, an application broken into several small modules takes considerably less time to compile than the same application stored in a single item.

The Pick/BASIC "@(x,y)" function speeds up from 10-20 times if the "term" definitions are compiled with the "o" option. For instance, if the current terminal is an IBM 3151 terminal, the "term ibm3151 (co" command compiles and produces FlashBASIC code for the terminal driver. This creates a hidden module for use with FlashBASIC code. For best results, use this feature with high baud rates and/or fast display devices.

Avoid user exits. Standard Pick/BASIC routines compiled with FlashBASIC will probably run just as fast, and possibly faster, than the same routines coded in virtual assembly.

Avoid disk I/O. If an application has read-only tables, it is best to read them all into memory at the beginning of the program rather than reading them piece-meal throughout execution. When reading an item, do a "matread" into a dimensioned array, rather than using several "readv's".

Choosing a FlashBASIC Level:

The "o" option may be followed by a number, from 1 to 9, which indicates the FlashBASIC (optimization) "level". If not specified, the level defaults to 1, which gives a large performance increase while minimizing compile time and object size. Higher levels increase object size by as much as 100% over that achieved with level 1, and increase compile time exponentially. Furthermore, levels above 1 yield relatively small performance increases for most applications. High levels also tend to use very large amounts of Unix or NT swap space. If the system runs out of swap space, FlashBASIC retries with a lower level. Line numbers (for error messages) and the state of variables within the debugger are also not guaranteed when using a level greater than one. Finally, the exact behavior of a specific level above one is undefined and may be different on different platforms or releases.

Pick Systems advises running routines with various levels to see if the run-time performance increase is worth the compile-time and object-size trade-offs. The best candidates for higher levels are small modules (less than about 200 lines) which have little or no string manipulation and lack significant amounts of screen or disk I/O. Using a level of 9 can cut in half such programs' run time as compared to their speed at level one, while not taking an unreasonably long time to compile.