> -----Original Message-----
> From: PaulMmn
> 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

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.