We are having severe speed problems with programs which were developed under ARev1 and now run under ARev3. Some reports run 100 times slower.

A popup displays a symbolic field which calls a program takes 20 times longer in ARev3 compared to ARev1. Even when the program contains only a RETURN statement it is very slow.

A processing program which reads records and processes them runs noticeably slower. Eg now takes one hour instead of 10 minutes.

Is there any way to get these programs back to a normal speed either through programming (eg not using symbolics) or externally (eg altering the CONFIG.SYS or AUTOEXEC.BAT files)?

Perhaps you can let us know some more details. eg. Is this network or standalone PC, which network, what type of PC, what the syntax of your program is, where the files live (local/network/mix) whether you are using the Netware LH NLM or just regular AREV. Also post your code for the symbolic and an idea of what you are trying to do. Then the helpful folk here can find a way to fix your problem.

Steve

Steve,

Many thanks for your offer.

We are running standalone PCs, NT and Novell. But it makes little difference.

We have since been able to isolate the main culprit as the XLATE:

 loop

    readnext @id else ...

    type=xlate('CUSTOMER.TRANS', @id, 1, 'X')

 repeat

We need these programs to run under both ARev1 and ARev3.

Using OPEN/READ made this program run in 5 minutes instead of 15 hours!

  open 'CUSTOMER.TRANS' TO CUSTOMER.TRANS ...

  loop

     readnext

     read @record from customer.trans .....

     type=@record

     repeat

The 'OPEN' command will open 'CUSTOMER.TRANS' in ARev1 and 'CUSTOMER_TRANS' in ARev3.

The XLATE seemed a good idea at the time - particularly for the lazy.

Janine,

Instead of xlates, sometimes it is better to write the full open and read logic.

There is no way around the file renaming problem, although you may be able to use the same symbolic formulaa in AREV 1.x by renaming the files there, or at least using SET-FILE based aliases for your data files (eg. have CLIENT_MASTER as a set-file under AREV 1.x to CLIENT.MASTER, then use the symbolics from AREV 3 and AREV 1 with common formulas)

Steve

Steve makes a good point about using the read/write logic because XLATE go thru it's LRU code before deciding how to handle the read.

However, if you don't have more than 64K of record IDS (or even if you do, but use the read logic to increment from LIST to LIST*2, etc),

the reading the list, CONVERT @FM to @RM and XLATING will work better. However, the return still has to be under 64K.

If you're not going to write, then opening the correct file and doing a READO instead of a read, then @RECORD (it's faster than FIELD) will really speed you up.

But you mention even a program with a RETURN is really slow. This sounds like a server that's short on memory. Also, in addition to Steve's -T, on Win95 be sure to turn off machine caching. It'll slow that machine down, but you don't get GFE's. Also, again, make the SORT file a LOCAL file. I create a VOLUME called AREVLOC that contains the sort path/file and also has it's own LISTS file - saves a lot of server I/O. Also, if you have popups or code files that seldom change, putting them on locally will really help. You can put an MFS on POPUPS (and MENUS, etc.) that will read local and then REMOTELY based on volume name, and you will find that the system is still faster.

View this thread on the forum...