So far I'm liking this option the best. Doing some simple math:
500,000 records * 12 passes through this loop for each record = 6,000,000 passes. (This def needs to be rethought, but may not be able to be avoided) Then multiply that by the numerous times the OS needs spin through who knows how many bytes to reach the 100, 101, 103, etc attribute to make a simple comparison. HELLO! (This CAN be avoided, therefore should be avoided) In my college days when the different sorting methods were still vying for dominance, it amazed me that a longer program actually sorted faster. Hmmm. That's when it occurred to me, compact code is not necessarily efficient code. Compact code may be pleasing to the eye of the programmer, but may very well be to the detriment of the user. Therefore it is my opinion that we, as programmers, must cater first to our customers and allow the intellect of our fellow brethren to glean wisdom and knowledge from their forefathers. :) Oh, and attending the U2U and listing CAREFULLY to the mumblings of the people who are wearing the ROCKET name tags is a tremendous help too! :-) By the way, I may even throw in some "SWAP @VM WITH @AM IN P12.101" to clean up those references a bit too. And of course SWAP them back. That however would likely only serve my vanity. :-) I'll let you all know if and what I discover. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com "Delivering Products, Services and Innovative Solutions" -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Allen E. Elwood Sent: Wednesday, March 02, 2011 10:22 PM To: 'U2 Users List' Subject: Re: [U2] Is this worth rewriting? 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 _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
