|
Simon, Please don't take my comments as any kind of criticism, that would be like biting the hand that feeds you. I saw the SETLL/READ sans (E) and was trying to rib you because of the "definitive" statement. I used to worry about whether one opcode was faster than another and have come to believe that it doesn't matter much, because I/O almost always sets the pace. About the only optimization that seems to help is to avoid moving or comparing large amounts of data. The I/O routines I wrote sit between an application and database server. These routines support things like GetRcd *NEXT, *FIRST, *EQUAL... you get the idea. I have found this extra layer adds a negligible amount of overhead, which is offset somewhat by the ability to really optimize I/O. Yes, I replaced the routine that used to trigger a READE which was a *NEXT w/key with a READ and key comparison. I am now exploring using the C library I/O routines and dumping the generated RPG I/O modules. David Morris >>> "Simon Coulter" <shc@flybynight.com.au> 03/15/99 05:21PM >>> Mello David, I agree with you. Using SETLL and READ(E) in place of CHAIN is just dumb -- although common enough. Proper use of blocking is generally the best single performance improvement that can be made to an application. It does rely on sequential processing and may need a sort of some sort. My original comments were specifically regarding the proper way to handle WRITEs and whether duplicate record checking should be performed before the WRITE. Regarding your I/O routines: Are you replacing an incoming request for read-equal-key with your own sequential table scan and a large blocking factor? Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
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.