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.REC200) 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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 X1,-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
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=X1,C I2=Y1,C ZC=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.REC200) 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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
Re: [U2] : Evaluating DCOUNT
Interesting ... certainly worth := trying! 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 Tom Whitmore Sent: Tuesday, February 12, 2013 1:43 PM To: U2 Users List 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=X1,C I2=Y1,C ZC=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.REC200) 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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
Re: [U2] : Evaluating DCOUNT
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 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=X1,C I2=Y1,C ZC=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.REC200) 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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 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=X1,C I2=Y1,C ZC=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.REC200) 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.REC200 D1 = LOOP UNTIL D1 = 0 REMOVE LINE.KEY FROM LINE.KEYS SETTING D1 loop
Re: [U2] : Evaluating DCOUNT
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=X1,C I2=Y1,C ZC=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 fastHow 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 REMOVEvirtual 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.REC200) 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 ofarray could change within the loop. Personally if the size ofarray is relatively small, DCOUNT is alright. However I've found REMOVE to be EXTREMELY faster and therefore use it whenever possible, even on smallarrays. For example, we have two files, a 'header' and 'detail' file. The keys to the 'detail' file are stored in attribute200 of the header file. So I'll pull the keys out of the header record, such: LINE.KEYS = HEADER.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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
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 antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org 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 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=X1,C I2=Y1,C ZC=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.REC200) 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
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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, February 12, 2013 3:24 PM To: u2-users@listserver.u2ug.org 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 antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org 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 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=X1,C I2=Y1,C ZC=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
Re: [U2] : Evaluating DCOUNT
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: tewhitm...@ratex.com To: u2-users@listserver.u2ug.org 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, February 12, 2013 3:24 PM To: u2-users@listserver.u2ug.org 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 antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org 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 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=X1,C I2=Y1,C ZC=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
Re: [U2] : Evaluating DCOUNT
It keeps track of the location of the last attribute touched. Not each one. -Original Message- From: Tom Whitmore tewhitm...@ratex.com To: U2 Users List u2-users@listserver.u2ug.org 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, February 12, 2013 3:24 PM To: u2-users@listserver.u2ug.org 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 antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org 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 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=X1,C I2=Y1,C ZC=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
Re: [U2] : Evaluating DCOUNT
Archive http://u2-universe-unidata.1073795.n5.nabble.com/ -Original Message- From: Dan Fitzgerald dangf...@hotmail.com To: u2-users u2-users@listserver.u2ug.org Sent: Tue, Feb 12, 2013 2:07 pm Subject: Re: [U2] : Evaluating DCOUNT 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: tewhitm...@ratex.com To: u2-users@listserver.u2ug.org 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, February 12, 2013 3:24 PM To: u2-users@listserver.u2ug.org 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 antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org 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 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=X1,C I2=Y1,C ZC=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
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 X1,-1 = 99 END NEXT I CRT CT -- Jeffrey Butera, PhD Associate Director for Application and Web Services Information Technology Hampshire College 413-559-5556 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] : Evaluating DCOUNT
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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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 X1,-1 = 99 END NEXT I CRT CT -- Jeffrey Butera, PhD Associate Director for Application and Web Services Information Technology Hampshire College 413-559-5556 ___ 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
Re: [U2] : Evaluating DCOUNT
David is correct (re: performance). Most of our app here have MV lists under 40-50 so it's not a huge issue. If you app has hundreds+ this could be a big challenge. Jeff Butera -- A tree falls the way it leans. Be careful which way you lean. The Lorax On Feb 11, 2013, at 8:30 AM, Dave Laansma dlaan...@hubbardsupply.com 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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 X1,-1 = 99 END NEXT I CRT CT -- Jeffrey Butera, PhD Associate Director for Application and Web Services Information Technology Hampshire College 413-559-5556 ___ 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
Re: [U2] : Evaluating DCOUNT
Jeff, My understanding is part of our problem is the fact that my multivalues are at position 200 and each time it has to count how many multivalues there are, it has to skim through the first 200 attributes, multivalues and subvalues to get to 200 before it even starts counting. So it's not so much of an issue of how many multivalues there are in 200, it's everything in 1-199 as well. Which in turn suggests that, when designing files, it may be a good idea to cluster your multivalue attributes near the beginning of your records. But that's another discussion. 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 8:35 AM To: U2 Users List Cc: U2 Users List Subject: Re: [U2] : Evaluating DCOUNT David is correct (re: performance). Most of our app here have MV lists under 40-50 so it's not a huge issue. If you app has hundreds+ this could be a big challenge. Jeff Butera -- A tree falls the way it leans. Be careful which way you lean. The Lorax On Feb 11, 2013, at 8:30 AM, Dave Laansma dlaan...@hubbardsupply.com 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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 X1,-1 = 99 END NEXT I CRT CT -- Jeffrey Butera, PhD Associate Director for Application and Web Services Information Technology Hampshire College 413-559-5556 ___ 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
Re: [U2] : Evaluating DCOUNT
Or use dimensioned arrays instead of dynamic arrays. John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, February 11, 2013 8:43 AM To: 'U2 Users List' Subject: Re: [U2] : Evaluating DCOUNT Jeff, My understanding is part of our problem is the fact that my multivalues are at position 200 and each time it has to count how many multivalues there are, it has to skim through the first 200 attributes, multivalues and subvalues to get to 200 before it even starts counting. So it's not so much of an issue of how many multivalues there are in 200, it's everything in 1-199 as well. Which in turn suggests that, when designing files, it may be a good idea to cluster your multivalue attributes near the beginning of your records. But that's another discussion. 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 8:35 AM To: U2 Users List Cc: U2 Users List Subject: Re: [U2] : Evaluating DCOUNT David is correct (re: performance). Most of our app here have MV lists under 40-50 so it's not a huge issue. If you app has hundreds+ this could be a big challenge. Jeff Butera -- A tree falls the way it leans. Be careful which way you lean. The Lorax On Feb 11, 2013, at 8:30 AM, Dave Laansma dlaan...@hubbardsupply.com 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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 X1,-1 = 99 END NEXT I CRT CT -- Jeffrey Butera, PhD Associate Director for Application and Web Services Information Technology Hampshire College 413-559-5556 ___ 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
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.REC200) 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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 X1,-1 = 99 END NEXT I CRT CT ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] : Evaluating DCOUNT
I think every time, since it's the second argument. If it doesn't matter, you can do for i = dcount(array,@fm) to 1 step -1 to have it evaluate once. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Peter Cheney Sent: Monday, February 11, 2013 12:15 AM To: U2 Users List (u2-users@listserver.u2ug.org) Subject: [U2] : Evaluating DCOUNT 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? Cheers Peter --- Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses, but advise you to carry out your own virus checks on this email and its attachments. We do not accept liability for any loss or damage caused by software viruses and do not represent that this transmission is free from viruses or other defects. Firstmac Limited (ABN 59 094 145 963) (AFSL 290600) --- ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Dave Davis Team Lead, RD P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.jpg] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]http://www.harriscomputer.com/ 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.comhttp://www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] : Evaluating DCOUNT
I have multiple views on this category of inquiry: I think only an engineer at RocketSoftware can answer this question. Some people actually use the non-optimization to their benefit. They count on the fact that the expression will be evaluated on every iteration, whether it's a DCount, Field, or some other calculation. Changing this could break applications. Evaluation of expressions might be dynamic - they might only re-evaluate if they need to. The BASIC runtime could setup a dirtyFlag on loops with an expression as an operand. If any component of the expression changes, set the flag. Next time through the iterator check the dirtyFlag. If it's set, then the expression must be re-evaluated, else use the previous value. However, a new problem here is that now there is a special check being set on every variable assignment, which can be a performance issue in itself. More variables involved in the expression means more runtime checks and performance can become worse than if it were just re-evaluating the one expression on every loop. This falls into the category of be careful what you wish for, you may get it. My bottom line is that we should strive for more options to define and override behaviors like this. We should have the option to make code behave as we expect, using compiler directives - and if a developer doesn't understand the options they're using, that's their problem, not a platform issue. THAT is what we should ask for when looking for features. It's not so much how it works, but knowing if it's possible to change behavior so that the runtime processes our code the way we want. Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula RD sells mv.NET and other Pick/MultiValue products worldwide, and provides related development services http://Nebula-RnD.com/blog Visit http://PickWiki.com! Contribute! http://Twitter.com/TonyGravagno http://groups.google.com/group/mvdbms From: Peter Cheney 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? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] : Evaluating DCOUNT
Yes it's assigned to a buffer and then decremented until it matches. The assign only takes place once. -Original Message- From: Ross Ferris ro...@stamina.com.au To: U2 Users List u2-users@listserver.u2ug.org Sent: Sun, Feb 10, 2013 11:05 pm Subject: Re: [U2] : Evaluating DCOUNT If order isn't important for dcount(array,@fm) to 1 step -1 *commands here next i Should only have the dcount evaluated once on any platform/release I believe Ross Ferris Stamina Software Visage Better by Design! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rick Nuckolls Sent: Monday, February 11, 2013 4:53 PM To: U2 Users List Subject: Re: [U2] : Evaluating DCOUNT The only way that this could not be an issue is if the compiler and the smarts and determined ahead of time that the array was invariant. My bet is solidly on plan b. -Rick On Feb 10, 2013, at 9:14 PM, Peter Cheney peter.che...@firstmac.com.au 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? Cheers Peter -- - Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses, but advise you to carry out your own virus checks on this email and its attachments. We do not accept liability for any loss or damage caused by software viruses and do not represent that this transmission is free from viruses or other defects. Firstmac Limited (ABN 59 094 145 963) (AFSL 290600) -- - ___ 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
Re: [U2] : Evaluating DCOUNT
You can also use a SELECT/SELECTV and then use a READNEXT in the loop -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Mon, Feb 11, 2013 5:30 am Subject: Re: [U2] : Evaluating DCOUNT 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.REC200 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.REC200,@VM) LINE.KEY = HEADER.REC200,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 X1,-1 = 99 END NEXT I CRT CT -- Jeffrey Butera, PhD Associate Director for Application and Web Services Information Technology Hampshire College 413-559-5556 ___ 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
Re: [U2] : Evaluating DCOUNT
The only way that this could not be an issue is if the compiler and the smarts and determined ahead of time that the array was invariant. My bet is solidly on plan b. -Rick On Feb 10, 2013, at 9:14 PM, Peter Cheney peter.che...@firstmac.com.au 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? Cheers Peter --- Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses, but advise you to carry out your own virus checks on this email and its attachments. We do not accept liability for any loss or damage caused by software viruses and do not represent that this transmission is free from viruses or other defects. Firstmac Limited (ABN 59 094 145 963) (AFSL 290600) --- ___ 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
Re: [U2] : Evaluating DCOUNT
If order isn't important for dcount(array,@fm) to 1 step -1 *commands here next i Should only have the dcount evaluated once on any platform/release I believe Ross Ferris Stamina Software Visage Better by Design! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rick Nuckolls Sent: Monday, February 11, 2013 4:53 PM To: U2 Users List Subject: Re: [U2] : Evaluating DCOUNT The only way that this could not be an issue is if the compiler and the smarts and determined ahead of time that the array was invariant. My bet is solidly on plan b. -Rick On Feb 10, 2013, at 9:14 PM, Peter Cheney peter.che...@firstmac.com.au 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? Cheers Peter -- - Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses, but advise you to carry out your own virus checks on this email and its attachments. We do not accept liability for any loss or damage caused by software viruses and do not represent that this transmission is free from viruses or other defects. Firstmac Limited (ABN 59 094 145 963) (AFSL 290600) -- - ___ 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
