Re: SETLL vs CHAIN performance comparisons

>
>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...
>
75 seconds vs 86 seconds and 84 seconds versus 62 seconds.  The timings
included below are for all 20,000 CHAINs and SETLLs.

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


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