× 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.



The benefit of varying-length variables is most evident when everything is varying - then there is no need for the %trim() function, which I think is the real performance hit - even a %trim() of a varying-length variable can go faster - it KNOWS where the end of the data is. %trim() on a fixed-length variable may have to go through almost the entire variable, if the value is significantly shorter than the full length.

I saw tremendously-improved performance when concatenating several character literals at a time to a varying-length variable. HUGE! Like this -

varchar = varchar + 'some character literal ';
varchar = varchar + 'some other character literal';

Of course, it wasn't exactly like that - there were conditional expressions and all that made this kind of thing OK to do.

HTH
Vern

On 9/17/2012 10:49 AM, Gqcy wrote:
Rorry,
(question 1)
I ran Jon's examples (added a printer file and timestamp calc's), and
did not see a difference between:
myBigVaryField = %Trim(myBigField) + %Trim(data2) + comma;
and
myBigVaryField += %Trim(data2) + comma;
(interesting to note, to do the "+=" you need the varying field, as that
operation is "numeric" (it creates a RNF7421 error if you use myBigField))



(question 2)
I changed the bif from %trimr to %trim, and the time did not appear to
be different.



Jon was correct in that using the varying field cut the time by a bit
more than half...

however, these examples proved to be linear, in that each iteration was
uniform, and not increased time wise as I stepped through the for loop.






On 9/16/2012 1:05 PM, Rory Hewitt wrote:
Jon,

2 questions I'm not sure of that you *may* be able to answer:

1. Is there any difference between what is generated at a low-level (W-code
or whatever) for "A = A + B" and "A += B"? I assume not, and that the
difference is merely in the RPG, but I don't know whether the compiler can
make any optimization based on the second example.

2. If one uses %Trim on a left-adjusted field (so there are no left spaces
to trim), what's the actual run-time overhead? I'm guessing there are a
couple of lines of code which get executed, but it can't honestly be much,
can it? Sure, there's still the right-trimming to be done, but is there a
noticeable difference between using %Trim and %TrimR on a left-adjusted
field, even through thousands of iterations (especially if there is
considerable trimming to be done on the right, which is what would take the
majority of the time). I could probably test this myself, but no doubt
wiser heads than mine (yours, for example), have already done this.

Rory

On Sun, Sep 16, 2012 at 9:15 AM, Jon Paris<jon.paris@xxxxxxxxxxxxxx> wrote:

On 2012-09-15, at 1:00 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

I would love to see some RPG examples of this.
Simplest one of all:

D myBigField s 20000a Inz
D myBigVaryField s 20000a Inz Varying

D data s 40a Inz('Only 12 used')

D comma c ','

D i s 5i 0 Inz

/Free

For i = 1 to 1000;
myBigField = %TrimR(myBigField) + %TrimR(data) + comma;
EndFor;

For i = 1 to 1000;
myBigVaryField += %TrimR(data) + comma;
EndFor;

*InLR = *On;

Try this and you'll see that the second (varying) version is orders of
magnitude faster. I've seen differences in excess of 1,000 times. I've also
seen versions worse than the first one in that they used %Trim in both
cases and not %TRimR.

And before anyone points it out, yes I know I probably don't want a comma
at the end of the data ;-)


Jon Paris

www.partner400.com
www.SystemiDeveloper.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.