RE: array handling

Your back-loading technique is a nifty one; I've archived your
explanation for future reference.

HOWEVER...

While I understand that a READ is more 'expensive' than a LOKUP
according to 'traditional' standards, but with the AS/400's
single-level store, and with the likelihood that a good chunk of your
table will already be in memory, how much performance can you gain by
loading a table, instead of chaining to the file each time?

Other techniques for table handling:

Make your table an array instead, and load it from a file by hand in
your program.  You can count the records and make sure you haven't
exceeded the number of slots available.  (I don't recall if an array
allows you to order the values; will this counter the binary search?)

Load your table until it's full; note which value is the high value
in the table, then chain to your file for every record that won't fit
in the table (and send a message to the programmer in charge!).

--Paul E Musselman
PaulMmn@ix.netcom.nospam.com




>  > -----Original Message-----
>>  From: Richard Reeve
>>
>>  Very interesting.  I had never really thought about
>>  'optimizing' an array, but it certainly makes good
>>  sense.  I appreciate the pointers.
>
>Well, it's really only an issue when you're dealing with performance, and
>since table caching is all about performance, it only makes sense to make it
>perform as well as possible.  The ASCEND trick is very simple to implement,
>so I thought I'd mention it.  The backloading technique is usually only
>required when you're writing tools, because the number of entries in your
>arrays can fluctuate wildly (for example, the number of field names in a
>program).  In most application circumstances, you can pretty much size the
>array as needed, so backloading is not required, but even in those
>circumstances the ASCEND technique makes sense.
>
>Anyway, I have to stop typing or I'll be a wreck today... but it was nice to
>find a situation where my copious knowledge of esoteric computer trivia was
>actually helpful <grin>.
>
>Joe