|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.