SETLL vs CHAIN performance comparisons

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