The speed increase is more likely due to the use of REMOVE not the RAISE
since REMOVE works also on values or sub-values and I don't think it
makes much difference which delimiter you use.
On ADDS Mentor we used to Basic select arrays to variables and then
READNEXT FROM in a loop since REMOVE was not available on that platform.
And that was very quick on large arrays too because SELECT TO with
READNEXT works in a similar way.
This method really only works on arrays with attribute marks, though.
On 12/02/2013 18:42, Tom Whitmore wrote:
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: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeffrey
Butera
Sent: Monday, February 11, 2013 7:55 AM
To: u2-users@listserver.u2ug.org
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
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
