But is it much faster than what you had to start with? Since both methods work, one might not be any better than the other. Although if your planning on using the HUB.REMOVE from multiple programs, then that course if most likely the best for your need.
George > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dave Laansma > Sent: Tuesday, November 18, 2008 11: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/
