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. -----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
