|
> -----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-2025 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.