Good News Everybody!
A new search engine is coming soon.
As a stop gap measure, we are using Google's custom search engine service.
|
midrange.com
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2026 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.
