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 <tewhitm...@ratex.com>
> To: U2 Users List <u2-users@listserver.u2ug.org>
> 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: 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
> 

_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to