× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@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
> 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.