|
>The longest time factor I had in using subprocedures >was allowing huge strings. And it specifically >had to do with using XLATE. My subprocedure >would capitalize up to a 32,000 byte string. I did some timings on %trim that were frightening. I found that defining the strings as 'varying' made a world of difference (making performance scream!) I ran this code: d loopLimit s 10u 0 inz(100000) d start s z d stop s z d duration s 10i 0 dNOP pr * inline c time start c do loopLimit c enddo c time stop c stop subdur start duration:*ms c duration dsply * procedure c time start c do loopLimit c callp NOP c enddo c time stop c stop subdur start duration:*ms c duration dsply c seton lr pNOP b dNOP pi p e And got these results: 21 ms 248 ms So yes, the procedure does indeed have overhead - a full order of magnitude worth. But for a hundred thousand iterations on an old 620 2 tenths of a second isn't really burdensome. Like Bob says, if you have a terribly time-critical function, move it inline (at least use /COPY!) but for the vast majority of applications, I can't imagine that this miniscule amount of overhead is going to be unreasonable, despite the large percentage change. --buck
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.