|
Bob Cozzi wrote: > Great idea Scott! > But remember, there is a lot of overhead in a procedure call (relative > to a straight, in-line opcode) so you will add to the time it takes to > retrieve the database records; if that's an issue with the code, the > you'd want to avoid wrapping it into a procedure. Sure, procedure calls have their overhead. But the overhead behind I/O operations is normally several orders of magnitude greater. If wrapping an I/O operation in a procedure makes for more maintainable code, then that's a very worthwhile trade-off, IMHO. > Ah, yet another reason why the INLINE keyword is needed on Procedure > specs.... Performance is a funny topic. In I/O bound applications (as are most RPG apps), there is relatively little to be gained by specific optimizations. The biggest gains are normally found by looking at overall algorithms, especially as they relate to I/O. In-lining, in particular, *may* provide some benefit, but on the other hand, it would also typically increase the size of the program object, which may adversely affect the paging characteristics of the program. Performance is always a tricky issue. Personally, I've tried code changes intended to improve performance only to be hit by even worse bottlenecks elsewhere! Hans
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.