Re: Arrays and Performance

["Raul A. Jager W." <raul@xxxxxxxxxx>]

I don't think pre-loading arrays will improve performance: if it is big,
it will cause the job to swap out, and if it is little, the "disk" read
will find the data in the memory buffer.

This kind of "performance improvement" where very usefull when we had
control of each machine operation, but in modern computers needs to be
tested under real work conditions, and comparing the direct read with
the pre-fech to see if there actualy is some improvement.


Scott Klement wrote:
> Hi Jonathan,
>
> Do you _know_ that preloading the file into an array, (and then using 
> array access) will improve the performance of your program?
>
> In most cases, I'd say that only improves performance for small files. 
> In the case of a larger file (assuming you're accessing the data by key 
> rather than RRN) I'd actually expect it to hurt performance.
>
> It takes time to read the whole file into an array.  That array will not 
> have a keyed access path, so the system will have to search every 
> record..   unless you're using a binary search, of course..  I assume 
> you're doing that, right?
>
> I guess I'm saying this:  Make sure you're not just doing this because 
> you _think_ it'll help.  Make sure you've measured performance and seen 
> that the CHAIN is a bottleneck.  Then make sure your replacement for it 
> is solving that bottleneck.
>
> Otherwise, you may be accomplishing nothing -- or even making things 
> worse -- plus making the code harder to maintain.
>
>
> On 8/4/2010 5:35 AM, Jonathan Mason wrote:
> > Hi All
> >
> > We have a number of programs, some in RPG/400 and others in RPG IV, that
> > load reference data from various files into arrays in an attempt to
> > reduce the performance impact of multiple chains to database files.
> >
> > 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.
> >
> > One thought was to use the arrays for the first however many records
> > would fit and then chain to the database file for the remaining records,
> > but there's concern about the performance impact of that approach.
> >
> > An alternative is to make use of user indexes, which could provide a lot
> > more space for storing entries, but we're not sure on the performance
> > impact of that approach.
> >
> > Does anybody have any knowledge of the performance benefits and pitfalls
> > of any of these approaches?  What do others do when faced with the same
> > problem?
> >
> > Thanks
> >
> >
> > Jonathan Mason
> >
> >
> > _______________________________________________________
> > This message was sent using NOCC v1.14 webmail software
> > _______________________________________________________