Buffering Messages in Advanced Revelation
Published By | Date | Version | Knowledge Level | Keywords |
---|---|---|---|---|
Revelation Technologies | 23 JAN 1990 | 2.X | INTERMEDIATE | @MESSAGES, MESSAGES, MSG, SUPPRESSING |
One of Advanced Revelation's more attractive features is the subroutine MSG. By calling MSG, you can present your own message to the user or call system messages to handle a variety of circumstances.
Each call to MSG involves some overhead. First, there is the subroutine call itself. There is also overhead involved in reading the message record from disk. Finally, there is the overhead of displaying the message, which involves clearing a portion of the screen and printing text to the appropriate positions.
By manipulating the message record, you can substantially reduce MSG overhead. One way is to prevent the display of the message altogether. Another way is to buffer messages in the system variable @MESSAGES. This eliminates the overhead of reading a message from the MESSAGES file.
Suppressing Message Display
Field one of the message record indicates what kind of message this is. For example, an A type message causes MSG to wait for user input before continuing, and a UB message type displays the message with a border and then continues processing.
The message type N indicates that the message should not be displayed. Any time MSG finds an N in field one of the message record the message will not be displayed. N type messages are typically used to suppress the display of system messages. However, they are also useful to reduce the overhead associated with displaying the message.
Buffering Messages in @MESSAGES
@MESSAGES is a system variable used to buffer frequently-called messages. The variable is made up of a series of message records.
Each record is separated by a record mark (@RM). The key of each message record is prefixed to the record and is separated from the record with a field mark. The @MESSAGES variable is prefixed with a record mark. A code fragment for determining which messages are in @MESSAGES is given in Figure 1.
Loading Messages into @MESSAGES
You can load message records into @MESSAGES in two ways. First, you can create a record in the MESSAGES file called IN.MEMORY, containing a list of messages to be buffered (delimited with @FM). If the system finds this record at logon, each message record with a key in the record is read into @MESSAGES.
In addition, a message is automatically read into @MESSAGES if field two of the message is B or RB. Only messages that are originally read from the MESSAGES file will be stored in @MESSAGES this technique cannot be used for messages created in a program.
If a message is in @MESSAGES, MSG will read the message record from there, rather than going to disk.
Test Results
To find out how much overhead is incurred by calls to MSG (and, thus, how much time can be saved) a simple program was written to call a UB type message 1,000 times. The results of the test are given in Table 1. By way of comparison, an empty loop executed in 1.87 seconds.
Conclusions and Cautions
If you want to improve program speed by manipulating messages, you have several options. The first is to turn off the message by changing its message type to N. This prevents the message from being displayed but does not eliminate the overhead of reading the disk.
The second option is to buffer the message. This eliminates the overhead of having to reread the message from disk but does not affect the overhead incurred in displaying the message.
The third option is to turn off the message and buffer it. The only remaining overhead is the call to MSG, and the minimal processing MSG performs to determine that the message is in memory but is not to be displayed.
Obviously, you can avoid the third option by simply not calling MSG. However, this method is useful to turn off messages called by system routines.
You should avoid the temptation to buffer all messages. Each message record stored in @MESSAGES takes up valuable string space, which can adversely affect other processes. If necessary, you can recover the string space by nulling out all or part of @MESSAGES. @MESSAGES will be refilled as R and RB messages are called.
Finally, not all UB messages can safely be turned off altogether. Some UB messages initialize a variable as part of their call. If the message has been turned off, the variable never gets initialized. This ultimately results in a Variable has not been assigned message when the DB (take the message down) message call is made.
Examples
Table 1
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Type ³ ÚÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄ´ ³ Buffer ³ UB ³ N ³ ÃÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ yes ³ 168.24 ³ 67.334 ³ ³ no ³ 119.47 ³ 12.41 ³ ÀÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÙ
Figure 1
CNT = COUNT(@MESSAGES, @RM) FOR CNTR = 1 TO CNT MESS_REC = FIELD(@MESSAGES,@RM,CNTR+1) MESS_KEY = MESS_REC<1> MESS_REC = DELETE(MESS_REC, 1, 0, 0) CALL MSG('The message key is %1%', , , MESS_KEY) CALL MSG('The message record is ':MESS_REC,'','','') NEXT CNTR