Unfortunately the content of this post is going to be pretty vague.

We've recently had reports of general system slowdowns across a number of client sites following an upgrade of their ARev application. I've tried to examine a number of possibilities including altered dictionary items, rogue MFSs and redundant/inefficient coding.

After quite a bit of feedback, the slowdown appears to based around the navigation and data entry in the windows and it seems to be almost all over the place i.e. it doesn't appear to be a specific validation routine a couple of windows.

Generally, the scenario is something like this:

- Enter a window and type in a record key, it will take maybe 5 seconds to load the record

- if I go back and enter in a new record key without exiting the window it takes about 1 second to load

- If I go back out of the window and enter in the second key that previously took just 1 second to load it now takes 5 seconds to load, just like the original

- Meaning if I enter a new window I will experience a delay on the first record entered, but not on subsequent entries. Exiting and reentering the window will reset the conditions

My thought was that maybe it was because the programs are not resident in memory on first entering the window and on subsequent records they are. If this sounds plausible or there are some other possible explanations, could someone please advise.

I know that what I've attempted to discuss is pretty vague and on most occasions we are talking of only seconds, but the slowdown is a fairly high order of magnitude.

TIA.

What you describe is definitely a program cacheing problem. Cameron Purdy has previously posted a superb cacheing program to get around this. Further optimisation is possible as this REVMEDIA article pointed out…

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

• NB Any unused WC_REGISTER% could be used

 IF WC_REGISTER% (3) THEN

      CALL VIDEO.RW(0,0,79,23,"W",WC_REGISTER%(3))

 END ELSE

      CALL VIDEO.RW(0,0,79,23,"R",WC_REGISTER%(3))

 END

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.

(Volume 2, Issue 2, Pages 5-8)

[email protected]

Sprezzatura Group

World Leaders in all things RevSoft

What the article describes is general window processing slowness. The original issue concerned slowness associated with a recent upgrade. It has been a few years, but I remember encountering this problem as well after upgrading from version 2.12 to 3.x. I don't know if we ever found the root cause of the problem, but repainting a screen resolved the problem.

If memory servers, repainting fixes the hidden label bug.

As for speed decreases moving to 3.12, it could be related to the window resolving the dot fields to underscores.

[email protected]

Sprezzatura Group

] If memory servers

That's what I need .. a memory server ;) .

Thanks for all the responses. I should be careful when I throw around the word "upgrade" - I really meant a programmatic upgrade not an ARev upgrade. Sorry, if I caused confusion.

The client I am talking about did undergo the "." to "_" conversion so maybe some slowness can be attributed to this recalculation. However, I have had reports from other clients also of slowness who have had this conversion done a long time ago and only now complain of slowness.

The slowness really seems to be loading the initial record in a window which sounds like the program cacheing problem. I'll check this out, I don't know if there is anything programmatic that we could have changed to cause this. We've at times actively tried to reduce the number of symbolics and xlates so I wouldn't have thought it was an increase of symbolic calculations.

Thanks, for shedding the light.

View this thread on the forum...