RevMedia

The chief complaint received regarding window processing addresses its lack of speed. There are ways of optimising this performance but they require an understanding of the window flow control and unfortunately accurate documentation of this is not provided with the product. There are two areas to address when considering user complaints - perceived slowness and actual slowness.

Perceived Slowness

When the user presses F8 or F9 there is generally a delay of a second or so before the screen clears. The user is unsure whether the key has actually connected and tries again thus adding to the delay. If the screen were to clear immediately the key was pressed the user would be happy even if the delay between screens remained the same. This trick can be easily accomplished. All that is required is that an image of a blank screen be captured and redisplayed whenever the user presses F8 or F9, in other words on a PRE.READ. The most convenient place to store such an image is in one of the registers because these are automatically reset to default values when the window is invoked. Thus on a pre read the existence of the screen image could be tested for. If present, it could be displayed., if not it could be loaded. A suitable piece of code hung off a commuter program on a pre read would be

Actual Slowness

The relative slowness of the window processor is caused by the amount of hooks into the applications generator provided by PAINT.. Extensive use of the SKELETON routine provided with the last utility diskette show that the program control flow for the window interpreter is as follows (assuming that no specific symbolic recalculation options have been set)

    Window Invoked
         Call all PREAPP processes
         Call PRE.INIT process
         Call POST.INIT process
         Call PRE.READ process
         For Each Prompt in Window
            If prompt has depth on screen (EG MVed)
               Call OCONV for each line (@MV = WC_MV% ="")
            Else
               Call OCONV for field
         Next

    Prompt for Key
         Call Key DFLT process
         Call Key PRE process
         Call OCONV process
         Call REP.SCRIBE process

         Call EDIT process
         Call OCONV process
         Call POST process
         Call OCONV process
         Call PER.PROC process

    Display Record
         Call PRE.READ process
         Call REP.READ process
         Call POST.READ process
         For Each Prompt in Window
            If Prompt has depth on screen
               If Prompt F Type
                  For X = 1 to Depth
                     Call OCONV for each line (@MV = WC_MV% ="")
                  Next
               If Prompt S Type
                  For X = 1 to Depth
                     Calculate Symbolic (@MV = WC_MV% = X)
                  Next
                  Call POST Process (@MV = Depth WC_MV% = "")
                  For X = 1 to Depth
                     Call OCONV for each line (@MV = Depth WC_MV% = "")
                  Next
            Else
               If Prompt F Type
                  Call OCONV process
                     If Prompt S Type
                        Calculate Symbolic
                        Call POST process
                        Call OCONV process
         Next Prompt

    Prompt for Field
         If WC_IS% = "" then Call DFLT process
         Call PRE process
         Call OCONV process
         Call REP.SCRIBE process
         Call EDIT/ICONV process
         Call OCONV process
         Call POST process
         Call OCONV process
         Call PER.PROC process
         For Each S Type Prompt in Window
             Calculate Symbolic
             Call POST Symbolic
             Call OCONV process
         Next

    Pass through Field
         If WC_IS% = "" then Call DFLT process
         Call PRE process
         Call OCONV process
         Call REP.SCRIBE process
         Call POST process
         Call OCONV process
         Call PER.PROC process

    Pass through Symbolic (when previous real field changed)
         Calculate Symbolic
         Call POST process
         Call OCONV process
         Call PER.PROC process
         For Each S Type Prompt in Window
             Calculate Symbolic
             Call POST process
             Call OCONV process
         Next

    Pass through Symbolic (when previous real field not changed)
         Calculate Symbolic
         Call POST process
         Call OCONV process
         Call PER.PROC process

    Save Record
         Call EDIT process for filed being prompted for (if field changed)
         Call POST process for field being prompted for
         Call PER.PROC process
         Call PRE.SAVE process
         If WC_OREC% # @RECORD then
            Call REP.WRITE
            Call POST.SAVE
         Load null@RECORD and @ID
         Call PRE.READ process
         Call OCONV process for all fields

    Press F8 Key
         Call OCONV for field being prompted for
         Call PRE.READ process
         Call OCONV process for all fields

    Delete Record
         Call PRE.DEL process
         Call REP.DEL process
         Call POST.DEL process
         Call OCONV process for all fields

    Exit Window
         Call POST.APP process

Studying the above details may provide many interesting insights into the modus operandi of the window interpreter. It explains why the window takes so long to display first time around (it has to call all of the unit logic, calculate all the symbolics and all the OCONVs on a screen with a blank dummy record and finally perform the key default and pre logic). It further explains why saving a record takes so long (it has to call the edit and post logic for the field we are currently on, the associated wrapup logic, calculate all the symbolics and all the OCONVs on a screen with a blank dummy record and finally perform the key default and pre logic). An interesting point to note is that the only processes attached to a symbolic that work are POST and PERPETUAL.

All of this may seem like overkill but a little thought shows that RevTech are just being thorough, none of these stages could be omitted if ALL possible circumstances are to be accommodated. Fortunately the average programmer does not have to cope with ALL possible circumstances. The environment in which the program will be running is generally known ahead of time.

This being the case we can short cut several of the above time consuming steps by careful modification of the template structure "on-the-fly". It is very unlikely (in the majority of applications) that when a record is saved (and before the next key has been prompted for) it will be necessary to call the PRE.READ process and all of the OCONVs with a blank record. Thus these could be removed from the template at PRE.SAVE and restored at PRE.READ (if @ID was not set to null, otherwise it should not be restored as this is the "dummy run"). The code to achieve this can be made generic and just slotted into the appropriate places in a commuter program. For those not wishing to undertake this coding exercise, example code to achieve this function will be presented in the next issue of REVMEDIA. Under certain circumstances this can dramatically reduce the time taken for a screen to F9 or F8. Note though that the performance improvement is dependant upon the individual characteristics of the screen. Those most likely to show improvement are those with OCONVs that XLATE to another file for a value and that have associated multivalues with user defined conversions.