Re: array handling -- MIDRANGE-L

Hi Joe,

How about changing the number of array elements from 20 to the max (32767?)
and rerunning it?  Since LOOKUP is doing a sequential search, I'm wondering
how much difference the size of the array makes.

Curious,
Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax

----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Sunday, December 02, 2001 9:29 PM
Subject: RE: array handling


> > -----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
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com