All right, I just went ahead and rewrote this the way I would do it since I
haven't written a single bit of code since I got laid off at the end of
September. And I did it while my wife and I are watching Judge Judy - it
was *fun* :-)
Granted I can't use real var names since I don't know what these are, but
using a simple var name replacement scheme, this illustrates what I would
consider the least amount of overhead for this.
A) reduced the overhead on the repetitive calls to over 100 attrs. The
system needs to look at *every single byte* in the record until it gets to
attr desired. If these are 25,000 byte records this would be a HUGE amount
of needless throughput which you can calc by (iterations - 2) * average
bytes to read before attr needed * number of times the statement is used in
the loop
B) Yup, got rid of the #. Not only does this make more sense, but # is
REALLY doing two comparisons: < and >
C) Got rid of the leading 7 digit indent to make it more readable
D) I don't see the necessity of testing three vars to see if they aren't
zero before adding them together. If they are zero, the equation will work.
If they are not zero, the equation will work. I can see maybe doing that if
the equation was doing any dividing to avoid the "can't divide by zero"
error, but not on adding.
E) I always make all my IF's block IF's to stub them out for future dev, as
well as to make them easier to read. So I did that at the bottom even
though it was just for one add stmt.
F) My eyes are really getting old. I need spaces between VARs and operands
so they don't smush together. So I spaced accordingly to make everything
just a tad more readable as well.
Now, this takes more lines of code. But many times more lines of code can
be way faster than fewer lines of code especially if the extra lines of code
are OUTSIDE of the loop.
MONTHLY.USAGE:
CM = MONTH + LY.CNT
P12.101 = PARMS(12)<101>
P12.133 = PARMS(12)<133>
P12.134 = PARMS(12)<134>
P7.100 = PARMS(7)<100>
P7.101 = PARMS(7)<101>
P7.102 = PARMS(7)<102>
FOR M = 1 TO 12
CUM(M) = P12.101<1,CM> + P12.133<1,CM> + P12.134<1,CM>
IF P7.100<1,CM> = '' THEN
CUMO(M) += P12.101<1,CM>
END ELSE
CUMO(M) += P7.100<1,CM>
END
IF P7.101<1,CM> = '' THEN
CUMO(M) += P12.133<1,CM>
END ELSE
CUMO(M) += P7.101<1,CM>
END
IF P7.102<1,CM> = '' THEN
CUMO(M) += P12.134<1,CM>
END ELSE
CUMO(M) += P7.102<1,CM>
END
CM -= 1
IF CM = 0 THEN
CM = 24
END
NEXT M
PARMS(12)<101> = P12.101
PARMS(12)<133> = P12.133
PARMS(12)<134> = P12.134
PARMS(7)<100> = P7.100
PARMS(7)<101> = P7.101
PARMS(7)<102> = P7.102
RETURN
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Keith Johnson
[DATACOM]
Sent: Wednesday, March 02, 2011 4:47 PM
To: '[email protected]'
Subject: Re: [U2] Is this worth rewriting?
Agreed that the dimensioned extract wouldn't make much difference, still the
attributes numbers are quite high.
The code below goes from 15 extracts maximum per for-next loop to 6.
I can't help but think this might mean something if it takes 90 minutes to
run.
001: MONTHLY.USAGE:
002: CM = MONTH + LY.CNT
003: FOR M = 1 TO 12
004: TEA = PARMS(12)<101,CM>
005: EAT = PARMS(12)<133,CM>
006: ATE = PARMS(12)<134,CM>
007: IF TEA # '' OR EAT # '' OR ATE # '' THEN CUM(M) = TEA + EAT + ATE
008: YAM = PARMS(7)<100,CM>
009: AMY = PARMS(7)<101,CM>
010: MYA = PARMS(7)<102,CM>
011: IF YAM # '' OR AMY # '' OR MYA # '' THEN
012: IF YAM # '' THEN CUMO(M) += YAM ELSE CUMO(M) += TEA
013: IF AMY # '' THEN CUMO(M) += AMY ELSE CUMO(M) += EAT
014: IF MYA # '' THEN CUMO(M) += MYA ELSE CUMO(M) += ATE
015: END
016: CM -= 1 ; IF CM = 0 THEN CM = 24
017: NEXT M
018: RETURN
So I'd say AYE - or YEA, if you use meaningful variables
Regards, Keith
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
