Re: Arrays and Performance

On Aug 4, 2010, at 1:00 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

The trouble with this approach is that the arrays are limited in size, a
maximum 9,999 elements in RPG/400 and 32,767 elements in RPG IV.

In the case of RPG IV this is no longer true as of V6.1. For that matter it was only true prior to V6.1 if you actually defined the arrays to RPG. If you just use a User Space or dynamic memory and qsort/bsearch this is not an issue.

For conventional RPG arrays _the_ critical factor is coding the ASCEND (or DESCEND) keyword. With these in place %LookUp will do a binary search and is very fast - faster than bsearch. Of course you do have to be sure that the array is in the sequence you said <grin>. It is the old LOOKUP op-code (and %lookup in cases without an ASC/DECend keyword) that has poor performance.

In tests I have run, the array approach outperforms a CHAIN or SETLL by many orders of magnitude. In one set of tests the difference was in excess of 10,000 to 1 and that is 1) after including the time to load the array _and_ 2) comparing against a CHAIN scenario where SETOBJACC had been used on the file. Remember when comparing the SETOBJACC scenario that by using that most of what you save is the physical disk reads. The path length through the I/O system is still fairly lengthy.

One approach that I have used in the past is to place the array in a User Space. Every time that you get a "miss" then CHAIN to the file. If found by CHAIN add it to an array of "updates" for the User Space array. At the end of the batch job add the updates to the end of the array and sort it. This avoids the overhead of having to load the array each day and ensures that your most frequently used products/ customers/codes are present in the array. Now it is ready for the next day. If you can prime the array by running a quick analysis over the last few days transactions you're ahead of the game.




Jon Paris

www.Partner400.com
www.SystemiDeveloper.com