On 12/02/13 19:04, Wjhonson wrote: > Correct me if I'm misunderstanding you Tom, but you said that field marks are > indexes so the first scan resolves where each field begins. That is not > correct, at least not literally. > > Count or Raising or Lowering or Scanning in general will not create an index > to the position of any fields. > The Remove maintains *A* (singular) pointer to where it's at, right now, as > it moves along. > It's not a fully indexed string. There's just a current position pointer. > One. > The thing here, is Tom said he used for/next, and not remove. Just as remove keeps track of the current position in the string, so does *field* access in a dynamic array!
So the original program had to scan the multi-value variable every single time round the loop. SLOW. The revised program, using RAISE, was scanning a multi-*field* variable, and BASIC's internal optimiser kept track of the current field. Effectively increasing the speed to pretty much the same as using REMOVE. Cheers, Wol > > > > > > > > -----Original Message----- > From: Tom Whitmore <[email protected]> > To: U2 Users List <[email protected]> > Sent: Tue, Feb 12, 2013 10:43 am > Subject: Re: [U2] : Evaluating DCOUNT > > > Hi, > When you have more than about 1,000 values in a field, changing the value > mark > to a field mark, is significant. I had a program that needed to work through > two fields with over 20,000 values. Initially, I left the strings as value > delimited, used a for/next loop and assigned the results to a new field > delimited string using <-1>. The program took about 15 minutes to perform > the > tasks needed. I then raised each string, used remove and concatenated > @FM:item. > It was done almost immediately, there was no perception of a delay getting to > TCL. To put it in code snippet, the first took 15 minutes and the second > took > maybe a second. > > X=20K values > Y=20K values > Z='' > MAX=DCOUNT(X,@VM) > FOR C=1 TO MAX > I1=X<1,C> > I2=Y<1,C> > Z<C>=I1*I2 > NEXT C > > > X=RAISE(20Kvalues) > Y=RASE(20Kvalues) > Z='' > LOOP > REMOVE I1 FROM X SETTING XPOS > REMOVE I2 FROM Y SETING YPOS > UNTIL I1='' AND I2='' AND XPOS=0 AND YPOS=0 > IF (Z) > THEN Z:=@AM:I1*I2 > ELSE Z=I1*I2 > REPEAT > > There are several things: > 1) REMOVE is faster than extract, especially when you are working with values > 2) Strings are treated different from dynamic arrays even though in theory > you > are doing the same thing (appending to the end of the string). > 3) COUNT will scan the string, then the extract will scan the string when it > is > value delimited. Field marks are indexes so the first scan resolves the > location where each field begins. > > Tom > RATEX Business Solutions > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > On Behalf Of Dave Laansma > Sent: Tuesday, February 12, 2013 1:21 PM > To: 'U2 Users List' > Subject: Re: [U2] : Evaluating DCOUNT > > Hey Allen, > > The REMOVE so fast <How fast is it?! "Match Game" throwback> that I suspect > the > time it takes to interpret the difference between a VM and AM is negligible. > I > could be wrong. > > And as far as using dimensioned arrays, agreed. They do seem to improve speed > ... but still not in comparison to the REMOVE <virtual bow to the REMOVE god>. > > Sincerely, > David Laansma > 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 Egerton > Sent: Monday, February 11, 2013 9:02 AM > To: U2 Users List > Subject: Re: [U2] : Evaluating DCOUNT > > David, > > You're correct that the remove is faster, and it is because it maintains an > internal pointer to the next item, as opposed to positioning to it for each > reference. > > And I'm pretty sure that you can make it run even faster with: > LINE.KEYS = RAISE(HEADER.REC<200>) > > As a matter of preference, I would set D1 to 999 or some other numeric value > rather than a null, only because Universe/Unidata is typeless, and I would be > afraid that the null, (""), might be treated as a zero; but that's just > personal > fear and preference not based on a horror story. > > > On 2/11/2013 8:30 AM, Dave Laansma wrote: >> I would HOPE that it evaluates it each time since the size of <array> could > change within the loop. >> >> Personally if the size of <array> is relatively small, DCOUNT is alright. > However I've found REMOVE to be EXTREMELY faster and therefore use it > whenever > possible, even on small <arrays>. >> >> For example, we have two files, a 'header' and 'detail' file. The keys to >> the > 'detail' file are stored in attribute <200> of the header file. So I'll pull > the > keys out of the header record, such: >> >> LINE.KEYS = HEADER.REC<200> >> D1 = "" >> LOOP UNTIL D1 = 0 >> REMOVE LINE.KEY FROM LINE.KEYS SETTING D1 >> <loop statements> >> REPEAT >> >> As opposed to: >> >> FOR V1 = 1 TO DCOUNT(HEADER.REC<200>,@VM) >> LINE.KEY = HEADER.REC<200,V1> >> <loop statements> >> NEXT V1 >> >> Based on historical dialogs on this subject on this forum, I have seen an > improvement in overall performance. >> >> Sincerely, >> David Laansma >> 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 Jeffrey >> Butera >> Sent: Monday, February 11, 2013 7:55 AM >> To: [email protected] >> Subject: Re: [U2] : Evaluating DCOUNT >> >> On 02/11/2013 12:14 AM, Peter Cheney wrote: >>> Hi Everyone, >>> >>> Does a DCOUNT get evaluated again for each iteration of a loop? >>> Or is UniVerse these days intelligent enough to keep track of what's going > on? >>> >>> e.g. >>> >>> for i = 1 to dcount(array,@fm) >>> *commands here >>> next i >>> >>> versus >>> >>> totalattributes = dcount(array,@fm) >>> for i = 1 to totalattributes >>> *commands here >>> next i >>> >>> Apart from readability and perhaps easier debugging is there an actual > internal difference? >>> I know it was an issue on older pick releases but I cannot remember if it > ever affected UV? >> >> Not sure about universe, but unidata defintely checks the DCOUNT for each > iteration. This produces 4 (not 2): >> >> >> CT=0 >> X=45:@VM:58 >> FOR I=1 TO DCOUNT(X,@VM) >> CT+=1 >> IF I<=2 THEN >> X<1,-1> = 99 >> END >> NEXT I >> CRT CT >> >> > > _______________________________________________ > 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 > > > _______________________________________________ > 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
