I agree with reasoning, but I have a slightly different methodology
I actually have my own methodology; I just failed to follow it. I personally find type abbreviations to be difficult to read and interpret quickly. For generic variables I usually just prefix "the", ie. thefile, thefolder, thename, etc. I never use "the" for a table or cursor field, so this ordinarily prevents the kind of problem I experienced yesterday.
Unfortunately, I had copied some old one-off code for this project in order to try to save some time. I need to remember that a lack of rigor will always eventually bite me.
Personally I am not a fan of the "M." prefix and find it unnecessary.
A member of the VFP Team (I can't remember his name; he was the guy who "took out the slow parts" from various subsystems for VFP 8 and 9) wrote a blog article explaining that without the M. prefix, the system MUST compare every variable referenced to every field in the current work area every time the variable is accessed to determine whether the variable is a field name. He said that if the current work area contains a large number of fields, and the same variable is used over a large number of iterations in a tight loop, using the M. prefix makes a considerable difference in speed. He showed test results to demonstrate this.
I do a LOT of array iteration. So I began using the M. prefix for variables inside high-iteration tight loops. I noticed a slight speed increase.
However, I find the M. prefix ugly and distracting. I used it yesterday as a quick fix to demonstrate what the problem was. I will probably eventually rename the variable.
Ken
On 2017-08-01 10:00, Ken Dibble wrote:
A member of the VFP Team (I can't remember his name; he was the guy who "took out the slow parts" from various subsystems for VFP 8 and 9) wrote a blog article explaining that without the M. prefix, the system MUST compare every variable referenced to every field in the current work area every time the variable is accessed to determine whether the variable is a field name. He said that if the current work area contains a large number of fields, and the same variable is used over a large number of iterations in a tight loop, using the M. prefix makes a considerable difference in speed. He showed test results to demonstrate this.
I do a LOT of array iteration. So I began using the M. prefix for variables inside high-iteration tight loops. I noticed a slight speed increase.
However, I find the M. prefix ugly and distracting. I used it yesterday as a quick fix to demonstrate what the problem was. I will probably eventually rename the variable.
Ken
Very interesting...thanks for sharing that!
I remember!! It was Calvin Hsia! Here's the blog article:
https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-t...
Ken
On 2017-08-01 10:00, Ken Dibble wrote:
A member of the VFP Team (I can't remember his name; he was the guy who "took out the slow parts" from various subsystems for VFP 8 and 9) wrote a blog article explaining that without the M. prefix, the system MUST compare every variable referenced to every field in the current work area every time the variable is accessed to determine whether the variable is a field name. He said that if the current work area contains a large number of fields, and the same variable is used over a large number of iterations in a tight loop, using the M. prefix makes a considerable difference in speed. He showed test results to demonstrate this. I do a LOT of array iteration. So I began using the M. prefix for variables inside high-iteration tight loops. I noticed a slight speed increase. However, I find the M. prefix ugly and distracting. I used it yesterday as a quick fix to demonstrate what the problem was. I will probably eventually rename the variable. Ken
Very interesting...thanks for sharing that!
[excessive quoting removed by server]
That's when I joined the m dot team. If Calvin recommended it, it seemed like good advice. š
--
rk
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken Dibble Sent: Tuesday, August 01, 2017 2:30 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
I remember!! It was Calvin Hsia! Here's the blog article:
https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-t...
Ken
That was a really interesting article so I took the example, expanded it to include an object property and ran the test on my system.
Here are my results: --------------------------------- y=1 nsec=SECONDS() FOR i = 1 to 1000000 * x=y && Results: 0.377 * x=m.y && Results: 0.151 * x=fld255 && Results: 0.328 * x=test.fld255 && Results: 0.201 * x=objSession.nValue && Results: 0.377 ENDFOR ?SECONDS()-nsec ---------------------------------
Most of my work is done moving data through temporary cursors and I ALWAYS reference fields with the table.field method shown in the fourth test. I also often use object properties to store static variables. While it looks like I'm getting the best results using table.field access; I'm not getting any performance advantage using object properties or by not using the m. prefix. The good news is now I know if I'm going to do a LOT of iterations with memory variables, there are some performance gains to be picked up by simply using the m. notation. I think I may keep these results in mind when I'm doing refactoring on my function library!
This has been quite the learning experience and I really appreciate Ken for sharing that article! It also proves that no matter how long you've been programming in ANY language there is always something new you can pick up. Thanks!
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken Dibble Sent: Tuesday, August 01, 2017 1:30 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
I remember!! It was Calvin Hsia! Here's the blog article:
https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-t ip-field-name-lookup-for-tables/
Ken
On 2017-08-01 10:00, Ken Dibble wrote:
A member of the VFP Team (I can't remember his name; he was the guy who "took out the slow parts" from various subsystems for VFP 8 and 9) wrote a blog article explaining that without the M. prefix, the system MUST compare every variable referenced to every field in the current work area every time the variable is accessed to determine whether the variable is a field name. He said that if the current work area contains a large number of fields, and the same variable is used over a large number of iterations in a tight loop, using the M. prefix makes a considerable difference in speed. He showed test results to demonstrate this. I do a LOT of array iteration. So I began using the M. prefix for variables inside high-iteration tight loops. I noticed a slight speed increase. However, I find the M. prefix ugly and distracting. I used it yesterday as a quick fix to demonstrate what the problem was. I will probably eventually rename the variable. Ken
Very interesting...thanks for sharing that!
[excessive quoting removed by server]
Personally I use this approach ...
STORE m.variable|obj.property|table.fieldname to variable. Fully qualify everything / always. Easier to debug as well.
Additional to results below ... STORE/ = | with/without m. | with/ without table open.
No Table Open x=y 0.1320 No Table Open STORE y to x 0.0870 No Table Open x=m.y 0.1328 No Table Open STORE m.y to x 0.0879 Table Open x=y 0.2081 Table Open STORE y to x 0.1644 Table Open x=m.y 0.1326 Table Open STORE m.y to x 0.0879 No Table Open STORE y to x 0.0870 No Table Open STORE m.y to x 0.0879 Table Open STORE m.y to x 0.0879 No Table Open x=y 0.1320 Table Open x=m.y 0.1326 No Table Open x=m.y 0.1328 Table Open STORE y to x 0.1644 Table Open x=y 0.2081
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: Wednesday, 2 August 2017 6:32 AM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
That was a really interesting article so I took the example, expanded it to include an object property and ran the test on my system.
Here are my results: --------------------------------- y=1 nsec=SECONDS() FOR i = 1 to 1000000 * x=y && Results: 0.377 * x=m.y && Results: 0.151 * x=fld255 && Results: 0.328 * x=test.fld255 && Results: 0.201 * x=objSession.nValue && Results: 0.377 ENDFOR ?SECONDS()-nsec ---------------------------------
Most of my work is done moving data through temporary cursors and I ALWAYS reference fields with the table.field method shown in the fourth test. I also often use object properties to store static variables. While it looks like I'm getting the best results using table.field access; I'm not getting any performance advantage using object properties or by not using the m. prefix. The good news is now I know if I'm going to do a LOT of iterations with memory variables, there are some performance gains to be picked up by simply using the m. notation. I think I may keep these results in mind when I'm doing refactoring on my function library!
This has been quite the learning experience and I really appreciate Ken for sharing that article! It also proves that no matter how long you've been programming in ANY language there is always something new you can pick up. Thanks!
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken Dibble Sent: Tuesday, August 01, 2017 1:30 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
I remember!! It was Calvin Hsia! Here's the blog article:
https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-t ip-field-name-lookup-for-tables/
Ken
On 2017-08-01 10:00, Ken Dibble wrote:
A member of the VFP Team (I can't remember his name; he was the guy who "took out the slow parts" from various subsystems for VFP 8 and 9) wrote a blog article explaining that without the M. prefix, the system MUST compare every variable referenced to every field in the current work area every time the variable is accessed to determine whether the variable is a field name. He said that if the current work area contains a large number of fields, and the same variable is used over a large number of iterations in a tight loop, using the M. prefix makes a considerable difference in speed. He showed test results to demonstrate this. I do a LOT of array iteration. So I began using the M. prefix for variables inside high-iteration tight loops. I noticed a slight speed increase. However, I find the M. prefix ugly and distracting. I used it yesterday as a quick fix to demonstrate what the problem was. I will probably eventually rename the variable. Ken
Very interesting...thanks for sharing that!
[excessive quoting removed by server]
On 2017-08-03 18:23, Darren wrote:
Personally I use this approach ...
STORE m.variable|obj.property|table.fieldname to variable. Fully qualify everything / always. Easier to debug as well.
Additional to results below ... STORE/ = | with/without m. | with/ without table open.
No Table Open x=y 0.1320 No Table Open STORE y to x 0.0870 No Table Open x=m.y 0.1328 No Table Open STORE m.y to x 0.0879 Table Open x=y 0.2081 Table Open STORE y to x 0.1644 Table Open x=m.y 0.1326 Table Open STORE m.y to x 0.0879
No Table Open STORE y to x 0.0870 No Table Open STORE m.y to x 0.0879 Table Open STORE m.y to x 0.0879 No Table Open x=y 0.1320 Table Open x=m.y 0.1326 No Table Open x=m.y 0.1328 Table Open STORE y to x 0.1644 Table Open x=y 0.2081
Can't argue with the numbers, but personally I've never liked STORE. No good reason I guess except it never felt normal (but hey, that's ok...use the Fox at its best, however that is!).
More typing, never seen the point.
A few thoughts: STORE can only refer to variables. FOR...ENDFOR loops only use variables.. The assignment x = y implies that x must be a variable (you cannot assign to a field using that syntax). The assignment x = m.y would remove any ambiguity.
There are a load more examples on the FoxWiki http://fox.wikis.com/wc.dll?Wiki~EssentialMDot~Wiki.
Laurie
On 4 August 2017 at 22:02, Alan Bourke alanpbourke@fastmail.fm wrote:
More typing, never seen the point.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
On Fri, 4 Aug 2017, at 10:49 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2017-08-03 18:23, Darren wrote:
Personally I use this approach ...
STORE m.variable|obj.property|table.fieldname to variable. Fully qualify everything / always. Easier to debug as well.
Additional to results below ... STORE/ = | with/without m. | with/ without table open.
No Table Open x=y 0.1320 No Table Open STORE y to x 0.0870 No Table Open x=m.y 0.1328 No Table Open STORE m.y to x 0.0879 Table Open x=y 0.2081 Table Open STORE y to x 0.1644 Table Open x=m.y 0.1326 Table Open STORE m.y to x 0.0879
No Table Open STORE y to x 0.0870 No Table Open STORE m.y to x 0.0879 Table Open STORE m.y to x 0.0879 No Table Open x=y 0.1320 Table Open x=m.y 0.1326 No Table Open x=m.y 0.1328 Table Open STORE y to x 0.1644 Table Open x=y 0.2081
Can't argue with the numbers, but personally I've never liked STORE. No good reason I guess except it never felt normal (but hey, that's ok...use the Fox at its best, however that is!).
[excessive quoting removed by server]
Based on results posted, I decided to do some real world testing with a customer file with real data to see what kind of results I would get.
BACKGROUND: Instead of using val() to convert text numbers to values, I have my own library function called txt2num which performs the conversion but it also strips out punctuation such as dollar signs and commas as well as handles signs whether in front or behind and it deals with decimals that go beyond two places all on the fly.
FIRST TEST: Importing a small text file of 25 columns, 350 rows and 12 thisform.library.txt2num() conversion procedures per row that's 4,200 calls to the function.
1) Base run - No mdot references: 1.529 seconds 2) After mdot added - mdot references added to function: 1.436 seconds.
That works out to about a 6% improvement in speed. Not a huge improvement but it was small file.
SECOND TEST: Importing a larger text file of 50 columns, 10261 rows and 12 thisform.library.txt2num() conversion procedures per row or about 123,132 calls to the function.
1) Base run - No mdot references: 5.101 seconds 2) After mdot added - mdot references added to function: 4.399 seconds.
That works out to about a 13.7% improvement in speed.
Not sure if the improvement scales consistently as file sizes increase. However, it seems to me perhaps the most effective use of the mdot notation may be in refactoring it into libraries or classes. That way you will get the most advantage from functions you call repeatedly. Plus as soon as you re-compile an existing program you can gain the speed advantages immediately without refactoring ALL your code.
As always, your mileage may vary.
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Darren Sent: Thursday, August 03, 2017 5:24 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
Personally I use this approach ...
STORE m.variable|obj.property|table.fieldname to variable. Fully qualify everything / always. Easier to debug as well.
Additional to results below ... STORE/ = | with/without m. | with/ without table open.
No Table Open x=y 0.1320 No Table Open STORE y to x 0.0870 No Table Open x=m.y 0.1328 No Table Open STORE m.y to x 0.0879 Table Open x=y 0.2081 Table Open STORE y to x 0.1644 Table Open x=m.y 0.1326 Table Open STORE m.y to x 0.0879 No Table Open STORE y to x 0.0870 No Table Open STORE m.y to x 0.0879 Table Open STORE m.y to x 0.0879 No Table Open x=y 0.1320 Table Open x=m.y 0.1326 No Table Open x=m.y 0.1328 Table Open STORE y to x 0.1644 Table Open x=y 0.2081
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: Wednesday, 2 August 2017 6:32 AM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
That was a really interesting article so I took the example, expanded it to include an object property and ran the test on my system.
Here are my results: --------------------------------- y=1 nsec=SECONDS() FOR i = 1 to 1000000 * x=y && Results: 0.377 * x=m.y && Results: 0.151 * x=fld255 && Results: 0.328 * x=test.fld255 && Results: 0.201 * x=objSession.nValue && Results: 0.377 ENDFOR ?SECONDS()-nsec ---------------------------------
Most of my work is done moving data through temporary cursors and I ALWAYS reference fields with the table.field method shown in the fourth test. I also often use object properties to store static variables. While it looks like I'm getting the best results using table.field access; I'm not getting any performance advantage using object properties or by not using the m. prefix. The good news is now I know if I'm going to do a LOT of iterations with memory variables, there are some performance gains to be picked up by simply using the m. notation. I think I may keep these results in mind when I'm doing refactoring on my function library!
This has been quite the learning experience and I really appreciate Ken for sharing that article! It also proves that no matter how long you've been programming in ANY language there is always something new you can pick up. Thanks!
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken Dibble Sent: Tuesday, August 01, 2017 1:30 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
I remember!! It was Calvin Hsia! Here's the blog article:
https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/foxpro-performance-t ip-field-name-lookup-for-tables/
Ken
On 2017-08-01 10:00, Ken Dibble wrote:
A member of the VFP Team (I can't remember his name; he was the guy who "took out the slow parts" from various subsystems for VFP 8 and 9) wrote a blog article explaining that without the M. prefix, the system MUST compare every variable referenced to every field in the current work area every time the variable is accessed to determine whether the variable is a field name. He said that if the current work area contains a large number of fields, and the same variable is used over a large number of iterations in a tight loop, using the M. prefix makes a considerable difference in speed. He showed test results to demonstrate this. I do a LOT of array iteration. So I began using the M. prefix for variables inside high-iteration tight loops. I noticed a slight speed increase. However, I find the M. prefix ugly and distracting. I used it yesterday as a quick fix to demonstrate what the problem was. I will probably eventually rename the variable. Ken
Very interesting...thanks for sharing that!
[excessive quoting removed by server]
Hi, It is a well known mistake that m.Dot is a speed improvement. Speed improvement is collotaral advantace. m.Dot is designed to make a string a true variable and not a field name. If you have a table with a field number and you contruct a function like: local number if number = 12 do something endif and you have a local variable number in this function, VFP ist looks for the value of the field number and not for the variabler number. Regards, Koen
2017-08-07 21:37 GMT+02:00 Paul H. Tarver paul@tpcqpc.com:
Based on results posted, I decided to do some real world testing with a customer file with real data to see what kind of results I would get.
BACKGROUND: Instead of using val() to convert text numbers to values, I have my own library function called txt2num which performs the conversion but it also strips out punctuation such as dollar signs and commas as well as handles signs whether in front or behind and it deals with decimals that go beyond two places all on the fly.
FIRST TEST: Importing a small text file of 25 columns, 350 rows and 12 thisform.library.txt2num() conversion procedures per row that's 4,200 calls to the function.
1) Base run - No mdot references: 1.529 seconds 2) After mdot added - mdot references added to function: 1.436seconds.
That works out to about a 6% improvement in speed. Not a huge improvement but it was small file.
SECOND TEST: Importing a larger text file of 50 columns, 10261 rows and 12 thisform.library.txt2num() conversion procedures per row or about 123,132 calls to the function.
1) Base run - No mdot references: 5.101 seconds 2) After mdot added - mdot references added to function: 4.399seconds.
That works out to about a 13.7% improvement in speed.
Not sure if the improvement scales consistently as file sizes increase. However, it seems to me perhaps the most effective use of the mdot notation may be in refactoring it into libraries or classes. That way you will get the most advantage from functions you call repeatedly. Plus as soon as you re-compile an existing program you can gain the speed advantages immediately without refactoring ALL your code.
As always, your mileage may vary.
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Darren Sent: Thursday, August 03, 2017 5:24 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
Personally I use this approach ...
STORE m.variable|obj.property|table.fieldname to variable. Fully qualify everything / always. Easier to debug as well.
Additional to results below ... STORE/ = | with/without m. | with/ without table open.
No Table Open x=y 0.1320 No Table Open STORE y to x 0.0870 No Table Open x=m.y 0.1328 No Table Open STORE m.y to x 0.0879 Table Open x=y 0.2081 Table Open STORE y to x 0.1644 Table Open x=m.y 0.1326 Table Open STORE m.y to x 0.0879
No Table Open STORE y to x 0.0870 No Table Open STORE m.y to x 0.0879 Table Open STORE m.y to x 0.0879 No Table Open x=y 0.1320 Table Open x=m.y 0.1326 No Table Open x=m.y 0.1328 Table Open STORE y to x 0.1644 Table Open x=y 0.2081
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: Wednesday, 2 August 2017 6:32 AM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
That was a really interesting article so I took the example, expanded it to include an object property and ran the test on my system.
Here are my results:
y=1 nsec=SECONDS() FOR i = 1 to 1000000 * x=y && Results: 0.377 * x=m.y && Results: 0.151 * x=fld255 && Results: 0.328 * x=test.fld255 && Results: 0.201 * x=objSession.nValue && Results: 0.377 ENDFOR ?SECONDS()-nsec
Most of my work is done moving data through temporary cursors and I ALWAYS reference fields with the table.field method shown in the fourth test. I also often use object properties to store static variables. While it looks like I'm getting the best results using table.field access; I'm not getting any performance advantage using object properties or by not using the m. prefix. The good news is now I know if I'm going to do a LOT of iterations with memory variables, there are some performance gains to be picked up by simply using the m. notation. I think I may keep these results in mind when I'm doing refactoring on my function library!
This has been quite the learning experience and I really appreciate Ken for sharing that article! It also proves that no matter how long you've been programming in ANY language there is always something new you can pick up. Thanks!
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken Dibble Sent: Tuesday, August 01, 2017 1:30 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
I remember!! It was Calvin Hsia! Here's the blog article:
https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/ foxpro-performance-t ip-field-name-lookup-for-tables/
Ken
On 2017-08-01 10:00, Ken Dibble wrote:
A member of the VFP Team (I can't remember his name; he was the guy who "took out the slow parts" from various subsystems for VFP 8 and 9) wrote a blog article explaining that without the M. prefix, the system MUST compare every variable referenced to every field in the current work area every time the variable is accessed to determine whether the variable is a field name. He said that if the current work area contains a large number of fields, and the same variable is used over a large number of iterations in a tight loop, using the M. prefix makes a considerable difference in speed. He showed test results to demonstrate this. I do a LOT of array iteration. So I began using the M. prefix for variables inside high-iteration tight loops. I noticed a slight speed increase. However, I find the M. prefix ugly and distracting. I used it yesterday as a quick fix to demonstrate what the problem was. I will probably eventually rename the variable. Ken
Very interesting...thanks for sharing that!
[excessive quoting removed by server]
If a convention is not being used for its intended purpose and is, in fact, optional, then it seems to me the unintended benefits may be the only things which matter to someone considering whether to start using the convention even in a limited way. Besides if you use variable naming conversions for memory variables and do not use the same naming convention for tables and fields and you always reference fields with table.field, then the intended purpose may be a weak argument in favor of its use.
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Koen Piller Sent: Monday, August 07, 2017 3:21 PM To: profoxtech@leafe.com Subject: Re: GETFILE() Returns Empty String in Some Cases
Hi, It is a well known mistake that m.Dot is a speed improvement. Speed improvement is collotaral advantace. m.Dot is designed to make a string a true variable and not a field name. If you have a table with a field number and you contruct a function like: local number if number = 12 do something endif and you have a local variable number in this function, VFP ist looks for the value of the field number and not for the variabler number. Regards, Koen
2017-08-07 21:37 GMT+02:00 Paul H. Tarver paul@tpcqpc.com:
Based on results posted, I decided to do some real world testing with a customer file with real data to see what kind of results I would get.
BACKGROUND: Instead of using val() to convert text numbers to values, I have my own library function called txt2num which performs the conversion but it also strips out punctuation such as dollar signs and commas as well as handles signs whether in front or behind and it deals with decimals that go beyond two places all on the fly.
FIRST TEST: Importing a small text file of 25 columns, 350 rows and 12 thisform.library.txt2num() conversion procedures per row that's 4,200 calls to the function.
1) Base run - No mdot references: 1.529 seconds 2) After mdot added - mdot references added to function: 1.436seconds.
That works out to about a 6% improvement in speed. Not a huge improvement but it was small file.
SECOND TEST: Importing a larger text file of 50 columns, 10261 rows and 12 thisform.library.txt2num() conversion procedures per row or about 123,132 calls to the function.
1) Base run - No mdot references: 5.101 seconds 2) After mdot added - mdot references added to function: 4.399seconds.
That works out to about a 13.7% improvement in speed.
Not sure if the improvement scales consistently as file sizes increase. However, it seems to me perhaps the most effective use of the mdot notation may be in refactoring it into libraries or classes. That way you will get the most advantage from functions you call repeatedly. Plus as soon as you re-compile an existing program you can gain the speed advantages immediately without refactoring ALL your code.
As always, your mileage may vary.
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Darren Sent: Thursday, August 03, 2017 5:24 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
Personally I use this approach ...
STORE m.variable|obj.property|table.fieldname to variable. Fully qualify everything / always. Easier to debug as well.
Additional to results below ... STORE/ = | with/without m. | with/ without table open.
No Table Open x=y 0.1320 No Table Open STORE y to x 0.0870 No Table Open x=m.y 0.1328 No Table Open STORE m.y to x 0.0879 Table Open x=y 0.2081 Table Open STORE y to x 0.1644 Table Open x=m.y 0.1326 Table Open STORE m.y to x 0.0879
No Table Open STORE y to x 0.0870 No Table Open STORE m.y to x 0.0879 Table Open STORE m.y to x 0.0879 No Table Open x=y 0.1320 Table Open x=m.y 0.1326 No Table Open x=m.y 0.1328 Table Open STORE y to x 0.1644 Table Open x=y 0.2081
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Paul H. Tarver Sent: Wednesday, 2 August 2017 6:32 AM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
That was a really interesting article so I took the example, expanded it to include an object property and ran the test on my system.
Here are my results:
y=1 nsec=SECONDS() FOR i = 1 to 1000000 * x=y && Results: 0.377 * x=m.y && Results: 0.151 * x=fld255 && Results: 0.328 * x=test.fld255 && Results: 0.201 * x=objSession.nValue && Results: 0.377 ENDFOR ?SECONDS()-nsec
Most of my work is done moving data through temporary cursors and I ALWAYS reference fields with the table.field method shown in the fourth test. I also often use object properties to store static variables. While it looks like I'm getting the best results using table.field access; I'm not getting any performance advantage using object
properties or by not using the m.
prefix. The good news is now I know if I'm going to do a LOT of iterations with memory variables, there are some performance gains to be picked up by simply using the m. notation. I think I may keep these results in mind when I'm doing refactoring on my function library!
This has been quite the learning experience and I really appreciate Ken for sharing that article! It also proves that no matter how long you've been programming in ANY language there is always something new you
can pick up.
Thanks!
Paul H. Tarver Tarver Program Consultants, Inc. Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken Dibble Sent: Tuesday, August 01, 2017 1:30 PM To: profoxtech@leafe.com Subject: RE: GETFILE() Returns Empty String in Some Cases
I remember!! It was Calvin Hsia! Here's the blog article:
https://blogs.msdn.microsoft.com/calvin_hsia/2004/12/14/ foxpro-performance-t ip-field-name-lookup-for-tables/
Ken
On 2017-08-01 10:00, Ken Dibble wrote:
A member of the VFP Team (I can't remember his name; he was the guy who "took out the slow parts" from various subsystems for VFP 8 and 9) wrote a blog article explaining that without the M. prefix, the system MUST compare every variable referenced to every field in the current work area every time the variable is accessed to determine whether the variable is a field name. He said that if the current work area contains a large number of fields, and the same variable is used over a large number of iterations in a tight loop, using the M. prefix makes a considerable difference in speed. He showed test results to demonstrate this. I do a LOT of array iteration. So I began using the M. prefix for variables inside high-iteration tight loops. I noticed a slight speed increase. However, I find the M. prefix ugly and distracting. I used it yesterday as a quick fix to demonstrate what the problem was. I will probably eventually rename the variable. Ken
Very interesting...thanks for sharing that!
[excessive quoting removed by server]
-
Alan Bourke -
AndyHC -
Darren -
Ken Dibble -
Koen Piller -
Laurie Alvey -
mbsoftwaresolutionsļ¼ mbsoftwaresolutions.com -
Paul H. Tarver -
Richard Kaye