David didn't indicate if he thought the program in question was a bottleneck. How many times per run would the file be accessed if a CHAIN is used? If the file has, say, 1,000 records and is accessed, say, 1,000,000 times per run, loading it into an array or using a user index might be beneficial. If the file is accessed, say, 10 times per run, I would use a CHAIN (or some such). Sometimes one can even cut down on the number of chains by asking, "Did I get the record I want on the previous Chain?"
I have one program (that comes to mind) that uses the array method. There are about 50 records in the table, but it is accessed anywhere from 200-300,000 times per run (night batch). Honestly, I never timed the different methods; it just seemed like a reasonable approach in that case. I doubt that I would use the array technique for an interactive program, unless we were talking about a real, real small file.
Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Wednesday, June 03, 2009 8:40 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Array vs file access
We have some old RPGIII that are using arrays instead of files.
These programs are used by a lot of different applications and can
be called many times by the same program. The programs in question
load a file into an array in the INZSR, then each time the program
is called, it's the array that is searched instead of the file.
Apparently, this is or was supposed to be quicker. The program
however, needs to be maintained as eventually the arrays get
overfilled as records get added to the file.
Is this kind of thing justified? If not, was it ever?
Yes - it most always will be justified but only you can compute the pain/gain
equation.
We've written a couple of articles related to this topic you can find them
here (
http://tinyurl.com/pk7ref and here
http://tinyurl.com/qxa4x4) it
includes some simple timing tests.
One thing you might think about - if the look up is being used by multiple
jobs, then the array could be loaded into a User Space so that it would not
increase the memory usage and the space would only have to be loaded (say)
once a day. All your code has to do is get the pointer. Assuming that the
file does not change frequently during the day, this would further reduce the
run time of the programs that use it since the build occurs only once a day.
In some case I have had a completely separate program build these arrays in
User Spaces and then used bsearch to search them. using bsearch means that the
array can grow dynamically since I never have to actually define it to RPG as
an array - just as a based field. The RPG Redbook "Who Knew You Could ..."
contains examples of bsearch.
In the past I've used the technique to significantly reduce as customer's
batch run times. Maintenance is admittedly a little more than for a simple
CHAIN in that as you note you have to update the maximum array size from time
to time but if you use %Lookup and limit the search to active elements and
make sure to use the ASCEND keyword on the array the look up speed is very
fast 'cos a binary search is performed.
Don't forget that even if you use SETOBJACC that all you have done is saved
the system from retrieving the data from disk (assuming it is still in real
memory). The code path length will still be far longer for a CHAIN than a
%LookUp because you are still going through all of the I/O routines.
Most batch routines are I/O bound not CPU - so making it a memory look up
removes it from the I/O stream and moves it to a CPU load.
Jon Paris
Partner400
www.Partner400.com
midrange.com
