As I recall, you will get IN.FIELD when MARK is set to '0' - showing it is the 'last item' in the group.
You will want to add that on I think -- I don't have a way to confirm this -- but I thought if you got a 0 or 1, the 'remove' still had something in it to 'share' -- See my example from yesterday... I think you'll miss the last segment with this version of the logic -- you need to treat 0 or 1 the same as a "2", except knowing it's the last iteration... DW > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dave Laansma > Sent: Tuesday, November 18, 2008 10:04 AM > To: [email protected] > Subject: RE: [U2] Speeding up processing through large dynamic table > > All right! Well, after evaluating the overwhelming response > to this seemingly simple question, I have experimented and > decided on the following approach. > > Embracing the risk of opening myself up to scrutiny of fellow > professionals with both greater and lesser wisdom than > myself, this is the path I have chosen. Feel free to provide > constructive criticism and/or blatant flaws in logic and > reason, and I'll take it into consideration. > > First, write a subroutine (I supposed it could have been a > FUNCTION) that performs the REMOVE for me. This subroutine > looks like this: > > SUBROUTINE HUB.REMOVE (IN.TAB,OUT.LINE,MARK) > > OUT.LINE = "" > MARK = "" > > LOOP > REMOVE IN.FIELD FROM IN.TAB SETTING MARK > > BEGIN CASE > CASE MARK = 0 > EXIT > > CASE MARK = 2 ; * @AM > OUT.LINE := IN.FIELD > EXIT > > CASE MARK = 3 ; * @VM > OUT.LINE := IN.FIELD : @VM > > CASE MARK = 4 ; * @SM > OUT.LINE := IN.FIELD : @SM > > END CASE > REPEAT > > 9999 > > RETURN > > END > > * IN.TAB is the whole table > * OUT.LINE is the attribute with all VM and SM in tact > * MARK = 0 is the flag to the CALLING program that we are finished. > > The calling program looks like this: > > LOOP > CALL HUB.REMOVE (IN.TAB,IN.REC,MARK) > IF MARK = 0 THEN EXIT > (do my thing with IN.REC) > REPEAT > > Conclusions I have arrived at: > > 1. LOOP/REMOVE/REPEAT is absolutely faster than FOR/NEXT > loop, especially as the size of the table grows into the 10's > of thousands 2. SWAP is a non-issue in regards to performance. > 3. It appears as though nesting REMOVEs would be bad. > 4. The 'pointer' the OS keeps track of is indeed maintained > to and from the CALL to my subroutine. This is good. > 5. This virtual users group is an EXCELLENT source for U2 > Software Engineers to learn more about the toolbox provided > by the UNIBASIC commands, theories and especially techniques > for accomplishing specific, targeted objectives. > 6. U2UG in Atlanta was very good. Still room for > improvement, but that will come as it evolves. > > Thank you ALL for your input. It certainly has been an > eye-opening exercise. There certainly are some 'interesting' > ideas out there. > > So, have it folks! I'll be watching! > > 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 David Laansma > Sent: Monday, November 17, 2008 1:10 PM > To: [email protected] > Subject: [U2] Speeding up processing through large dynamic table > > Is there a way to speed up spinning through a very large > dynamic table? > Here is > a sample of my program: > > A11 = DCOUNT(IN.TAB,@AM) > > FOR A1 = 1 TO A11 > IN.LINE = IN.TAB<A1> > SWAP @VM WITH @AM IN IN.LINE > CUST.NUM = IN.LINE<1> > CUST.DESC = IN.LINE<2> > NEXT A1 > > A11 is 85,000+ and as this loop goes on, this thing get really slow. > Any tips > on speeding this up? > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
