I don't know if the old list archives are available, but iirc, either Glen
Herbert or Mark Baldridge posted a pretty detailed description of how it works,
focusing on the RAISE function.
> From: [email protected]
> To: [email protected]
> Date: Tue, 12 Feb 2013 16:46:20 -0500
> 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
