It keeps track of the location of the last attribute touched. Not each one.
-----Original Message----- From: Tom Whitmore <[email protected]> To: U2 Users List <[email protected]> Sent: Tue, Feb 12, 2013 1:46 pm Subject: Re: [U2] : Evaluating DCOUNT My understanding is that UniVerse keeps track of the location of each attribute the first time is hits an attribute. U2 support will need to provide a definitive answer. I do know that we have found field marks are measurably faster than value marks, and concatenating strings is measurably faster than using dynamic array functions, anytime we go over about 1,000 values. Remove definitely helps, but most of our code is old and is still using for/next loops. Tom Whitmore RATEX Business Solutions -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Wjhonson Sent: Tuesday, February 12, 2013 3:24 PM To: [email protected] Subject: Re: [U2] : Evaluating DCOUNT Yes it keeps track of the position of the current field (only), not each field. It's not indexed. Its just a one value pointer. -----Original Message----- From: Wols Lists <[email protected]> To: u2-users <[email protected]> Sent: Tue, Feb 12, 2013 12:16 pm Subject: Re: [U2] : Evaluating DCOUNT 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 _______________________________________________ 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
