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: [email protected]
-----Original Message-----
From: ProfoxTech [mailto:[email protected]] On Behalf Of Darren
Sent: Thursday, August 03, 2017 5:24 PM
To: [email protected]
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:[email protected]] On Behalf Of Paul H.
Tarver
Sent: Wednesday, 2 August 2017 6:32 AM
To: [email protected]
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: [email protected]
-----Original Message-----
From: ProfoxTech [mailto:[email protected]] On Behalf Of Ken
Dibble
Sent: Tuesday, August 01, 2017 1:30 PM
To: [email protected]
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]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
