|
> -----Original Message----- > From: PaulMmn > > 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? Well, when I have a question like this, I test it. A R TABLER A KEY 2A A VALUE 2A A K KEY Add, say, eight or ten records. Run the following program. On my machine, a little model 270, I find that values up to a million are nice. FMYTABLE IF E K DISK D ARY1 S 2 DIM(20) ASCEND D ARY2 S 2 DIM(20) D XCLOAD C CONST('0102091812283144') * D TIMES DS D T1A 6 D T1B 8 13 D T2A 15 20 D T2B 22 27 * D TIME1A s 6 0 D TIME1B s 6 0 D TIME2A s 6 0 D TIME2B s 6 0 D X s 3 0 D XICNT s 15 5 D XWCNT s 10 0 D XWWORK s 2 D Y s 3 0 * C *ENTRY PLIST C PARM XICNT C Z-ADD XICNT XWCNT * C MOVEA *HIVAL ARY1 C MOVEA XCLOAD ARY1 * C TIME TIME1A C 1 DO XWCNT C 1 DO 8 X C MOVE ARY1(X) XWWORK C EXSR GETA C ENDDO C ENDDO C TIME TIME2A * C TIME TIME1B C 1 DO XWCNT C 1 DO 8 X C MOVE ARY1(X) XWWORK C EXSR GETB C ENDDO C ENDDO C TIME TIME2B * C MOVE TIME1A T1A C MOVE TIME2A T2A C MOVE TIME1B T1B C MOVE TIME2B T2B C TIMES DSPLY * C MOVE *ON *INLR * C GETA BEGSR C XWWORK CHAIN MYTABLE 90 C ENDSR * C GETB BEGSR C Z-ADD 1 Y C XWWORK LOOKUP ARY1(X) 90 C ENDSR Run on a dedicated machine with a parameter of 250000 (a quarter of a million), I get the following message in QSYSOPR: 000643 000902 000902 000903 That translates to 139 seconds for CHAIN, 1 second for LOOKUP. A trained eye could argue that we could conceivably be as high as 2 seconds for the LOOKUP, but even then the database I/O is over 50 times slower, single-level store notwithstanding. Here's a second run, with a parameter of an even million: 001026 001857 001857 001901 Let's see, that's 8min31sec, or 511 seconds for I/O, and four, maybe five seconds for the lookups. Arrays are 100 times faster than database I/O in this particular case. I won't go off into a rant, but suffice to say that a little intelligent coding can always make a program faster. Optimizers are nice, but all code is NOT created equal, and nothing beats the human touch - experience, intuition and above all, TESTING - for deciding which technique makes sense in a given environment. Joe Pluta www.plutabrothers.com
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.