Re: SETLL vs CHAIN performance comparisons

Don - do what makes you feel good!

In a message dated 97-05-27 14:19:39 EDT, you write:

<< From:        dr2@access.digex.net (Don)
 Sender:        mcsnet!midrange.com!midrange-l-owner@Mcs.Net
 Reply-to:      MIDRANGE-L@midrange.com
 To:    cmassoglia@voyager.net (Charlie Massoglia)
 CC:    MIDRANGE-L@midrange.com
 
 
 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
 > 5 >>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *