Re: SETLL vs CHAIN performance comparisons

The order you ran these jobs may effect the timings.                            
                

The first time you run a job, it takes longer than the second time you run
the same job.  The first time the records and indexes must be paged in. 
The second time, they are already in memory.

Steven Easton
seaston@ionet.net
http://www.ionet.net/virtual/dpma/

----------
> From: Don <dr2@access.digex.net>
> To: Charlie Massoglia <cmassoglia@voyager.net>
> Cc: MIDRANGE-L@midrange.com
> Subject: Re: SETLL vs CHAIN performance comparisons
> Date: Tuesday, May 27, 1997 10:01 AM
> 
> 
> Charlie,
> 
> How long did it take to do the 20k operations??  How much time/sec is the
> savings/loss????   Sounds like it's not much in either case unless 
> you're doing some MAJOR volume...
> 
> On Mon, 26 May 1997, Charlie Massoglia wrote:
> 
> > I have just completed some performance testing between SETLL and CHAIN.
 Two
> > different RPG IV prorams using 20,000 CHAINs versus SETLLs on a 130,000
> > record file on a Model F04 yielded the following results:
> > 
> > 1.  If ALL records are found, SETLL is more efficient than CHAIN (75
seconds
> > versus 86 seconds).  
> > 
> > 2.  If NO records are found, SETLL is less efficient than CHAIN (84
seconds
> > versus versus 62 seconds).
> > 
> > It does not matter whether or not any fields in the record format are
> > referenced in the program.  I tried it both ways.
> > 
> > It would appear that if you know the SETLL/CHAIN is likely to find the
> > record, use SETLL.  If the SETLL/CHAIN is unlikely to find the record,
use
> > CHAIN.
> > 
> > I am very suprised with these results.  They are not consistent with
what
> > how I thought SETLL and CHAIN worked.
> > 
> > I can only assume in the first sample, the amount of time it takes to
bring
> > the input buffer into the program on the CHAIN exceeds the amount of
time it
> > takes to position the file cursor on the SETLL causing the SETLL to be
more
> > efficient than the CHAIN when records are found.  In the second sample,
> > since no record is ever found, there is no overhead to bring the input
> > buffer into the program on the CHAIN so the overhead of positioning the
file
> > cursor in the SETLL makes the SETLL less efficient than the CHAIN when
> > records are NOT found.
> > 
> > Can anyone in Toronto confirm this?
> > 
> > Finally, in case you are wondering, an unsuccesful CHAIN does NOT
reposition
> > the file cursor.  At the start of the program if you CHAIN out to key
20000
> > which is not in the file followed by a READ, you get key 1.
> > 
> > 
> > 
> >  
> > 
> > 
> > Charlie Massoglia, Massoglia Technical Consulting, Inc.
> > PO Box 1065, Okemos, MI 48854, USA
> > 517-676-9700  Fax: 517-676-1006  EMAIL: cmassoglia@voyager.net
> > 
> > 
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
> > * This is the Midrange System Mailing List!  To submit a new message,  
*
> > * send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from    
*
> > * this list send email to MAJORDOMO@midrange.com and specify           
*
> > * 'unsubscribe MIDRANGE-L' in the body of your message.  Questions     
*
> > * should be directed to the list owner / operator: david@midrange.com  
*
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
> > 
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This is the Midrange System Mailing List!  To submit a new message,   *
> * send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
> * this list send email to MAJORDOMO@midrange.com and specify            *
> * 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
> * should be directed to the list owner / operator: david@midrange.com   *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> umidr
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *