Fellow Foxers, Just a little aside to late Wednesday afternoon:
I have a heavyweight data entry program in VFP written which supports one monster form with pageframes stacked inside each other each page containing various visual classes down to up to 10 levels.
This form is now showing its age as it has been added to over some 20 years and never been streamlined or optimised in any way. The main problem is that the switching from the main form pageframe onto each of the 10 tabs in the pageframe is somewhat slow running on the network and I am sure that it is all the Draw(), Paint() and refresh repeat calls that are affecting it.
So, I have decided to rip it apart and find out just where the majority of the repeat "refresh" coding is being done.
I thought I could initially use the event Logger but it doesn't log calls to any refresh methods so then I turned my mind to the coverage logger which doesn't really help me at all.
Anyone any ideas as to how I can easily accumulate the calls to the various controls refresh methods and get some simple statistics to have a look at where all the processing effort is going?
All I can think of is to programmatically bind a "logging procedure" event to each control's refresh event and then log the results into something like a csv table for further analysis or at worst, log events by collecting information from the refresh events in the base classes for each control but that would be very long winded.
Any other ideas other than those mentioned?
Dave
You could use the coverage profiler.
Frank.
Frank Cazabon
On 06/09/2017 11:16 AM, Dave Crozier wrote:
Fellow Foxers, Just a little aside to late Wednesday afternoon:
I have a heavyweight data entry program in VFP written which supports one monster form with pageframes stacked inside each other each page containing various visual classes down to up to 10 levels.
This form is now showing its age as it has been added to over some 20 years and never been streamlined or optimised in any way. The main problem is that the switching from the main form pageframe onto each of the 10 tabs in the pageframe is somewhat slow running on the network and I am sure that it is all the Draw(), Paint() and refresh repeat calls that are affecting it.
So, I have decided to rip it apart and find out just where the majority of the repeat "refresh" coding is being done.
I thought I could initially use the event Logger but it doesn't log calls to any refresh methods so then I turned my mind to the coverage logger which doesn't really help me at all.
Anyone any ideas as to how I can easily accumulate the calls to the various controls refresh methods and get some simple statistics to have a look at where all the processing effort is going?
All I can think of is to programmatically bind a "logging procedure" event to each control's refresh event and then log the results into something like a csv table for further analysis or at worst, log events by collecting information from the refresh events in the base classes for each control but that would be very long winded.
Any other ideas other than those mentioned?
Dave
[excessive quoting removed by server]
On Wed, Sep 6, 2017 at 11:30 AM, Frank Cazabon frank.cazabon@gmail.com wrote:
You could use the coverage profiler.
Frank.
Some pointers: http://spacefold.com/lisa/oldsite/LSN_CoverageExtend.aspx
Ted, I might have known Lisa would have done some of her wizardry and as she says in the intro the coverage profiled on its own is fairly worthless!
Good find.... it may well help in phase 2.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Ted Roche Sent: 06 September 2017 16:57 To: profox@leafe.com Subject: Re: Event logging
On Wed, Sep 6, 2017 at 11:30 AM, Frank Cazabon frank.cazabon@gmail.com wrote:
You could use the coverage profiler.
Frank.
Some pointers: http://spacefold.com/lisa/oldsite/LSN_CoverageExtend.aspx
[excessive quoting removed by server]
The latest version of GoFish is GoFish 5.0.163 released 2017-02-12
You can get it through Thor, or from this download link:
https://github.com/mattslay/GoFish/archive/master.zip
The project has moved from VFPx/Codeplex to GitHub. Here's the link to the new repo on GitHub: https://github.com/mattslay/GoFish
On 9/6/17 10:57 AM, Ted Roche wrote:
On Wed, Sep 6, 2017 at 11:30 AM, Frank Cazabon frank.cazabon@gmail.com wrote:
You could use the coverage profiler.
Frank.
Some pointers: http://spacefold.com/lisa/oldsite/LSN_CoverageExtend.aspx
[excessive quoting removed by server]
As Matt mentioned, GF5 has been out for a while and it is quite stable.
If you decide to revisit the coverage profiler, this add-on for analyzing coverage logs can be quite helpful. It's a little rough around the edges but it does help you drill into how your code is running. I have a little bit of code built into the load event of my baseform class that lets me turn on coverage logging as needed.
http://gorila.netlab.cz/cvp.html
--
rk
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ted Roche Sent: Wednesday, September 06, 2017 11:57 AM To: profoxtech@leafe.com Subject: Re: Event logging
On Wed, Sep 6, 2017 at 11:30 AM, Frank Cazabon frank.cazabon@gmail.com wrote:
You could use the coverage profiler.
Frank.
Some pointers: http://spacefold.com/lisa/oldsite/LSN_CoverageExtend.aspx
And having just really read your original query, Dave, I would highly recommend getting CVP and generating coverage logs to analyze with it.
--
rk
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Richard Kaye Sent: Thursday, September 07, 2017 7:51 AM To: profoxtech@leafe.com Subject: RE: Event logging
As Matt mentioned, GF5 has been out for a while and it is quite stable.
If you decide to revisit the coverage profiler, this add-on for analyzing coverage logs can be quite helpful. It's a little rough around the edges but it does help you drill into how your code is running. I have a little bit of code built into the load event of my baseform class that lets me turn on coverage logging as needed.
http://gorila.netlab.cz/cvp.html
--
rk
Unfortunately, the coverage profiler doesn't help Frank.
Koen's suggestion of GoFish4 has given me more than enough information to get going on tracking down the poor performance.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Frank Cazabon Sent: 06 September 2017 16:30 To: profox@leafe.com Subject: Re: Event logging
You could use the coverage profiler.
Frank.
Frank Cazabon
On 06/09/2017 11:16 AM, Dave Crozier wrote:
Fellow Foxers, Just a little aside to late Wednesday afternoon:
I have a heavyweight data entry program in VFP written which supports one monster form with pageframes stacked inside each other each page containing various visual classes down to up to 10 levels.
This form is now showing its age as it has been added to over some 20 years and never been streamlined or optimised in any way. The main problem is that the switching from the main form pageframe onto each of the 10 tabs in the pageframe is somewhat slow running on the network and I am sure that it is all the Draw(), Paint() and refresh repeat calls that are affecting it.
So, I have decided to rip it apart and find out just where the majority of the repeat "refresh" coding is being done.
I thought I could initially use the event Logger but it doesn't log calls to any refresh methods so then I turned my mind to the coverage logger which doesn't really help me at all.
Anyone any ideas as to how I can easily accumulate the calls to the various controls refresh methods and get some simple statistics to have a look at where all the processing effort is going?
All I can think of is to programmatically bind a "logging procedure" event to each control's refresh event and then log the results into something like a csv table for further analysis or at worst, log events by collecting information from the refresh events in the base classes for each control but that would be very long winded.
Any other ideas other than those mentioned?
Dave
[excessive quoting removed by server]
Why not? It's purpose is to help you track down the slow parts of your application.
On 6 September 2017 11:58:29 GMT-04:00, Dave Crozier DaveC@Flexipol.co.uk wrote:
Unfortunately, the coverage profiler doesn't help Frank.
Koen's suggestion of GoFish4 has given me more than enough information to get going on tracking down the poor performance.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Frank Cazabon Sent: 06 September 2017 16:30 To: profox@leafe.com Subject: Re: Event logging
You could use the coverage profiler.
Frank.
Frank Cazabon
On 06/09/2017 11:16 AM, Dave Crozier wrote:
Fellow Foxers, Just a little aside to late Wednesday afternoon:
I have a heavyweight data entry program in VFP written which supports
one monster form with pageframes stacked inside each other each page containing various visual classes down to up to 10 levels.
This form is now showing its age as it has been added to over some 20
years and never been streamlined or optimised in any way. The main problem is that the switching from the main form pageframe onto each of the 10 tabs in the pageframe is somewhat slow running on the network and I am sure that it is all the Draw(), Paint() and refresh repeat calls that are affecting it.
So, I have decided to rip it apart and find out just where the
majority of the repeat "refresh" coding is being done.
I thought I could initially use the event Logger but it doesn't log
calls to any refresh methods so then I turned my mind to the coverage logger which doesn't really help me at all.
Anyone any ideas as to how I can easily accumulate the calls to the
various controls refresh methods and get some simple statistics to have a look at where all the processing effort is going?
All I can think of is to programmatically bind a "logging procedure"
event to each control's refresh event and then log the results into something like a csv table for further analysis or at worst, log events by collecting information from the refresh events in the base classes for each control but that would be very long winded.
Any other ideas other than those mentioned?
Dave
[excessive quoting removed by server]
Dave, 1) I would install GoFish4 this application can list you all the calls to Refresh() 2) I would comment all thisform.refresh for a starter except in the activate event of Page this usualy helps enourmously
Regards, Koen
2017-09-06 17:16 GMT+02:00 Dave Crozier DaveC@flexipol.co.uk:
Fellow Foxers, Just a little aside to late Wednesday afternoon:
I have a heavyweight data entry program in VFP written which supports one monster form with pageframes stacked inside each other each page containing various visual classes down to up to 10 levels.
This form is now showing its age as it has been added to over some 20 years and never been streamlined or optimised in any way. The main problem is that the switching from the main form pageframe onto each of the 10 tabs in the pageframe is somewhat slow running on the network and I am sure that it is all the Draw(), Paint() and refresh repeat calls that are affecting it.
So, I have decided to rip it apart and find out just where the majority of the repeat "refresh" coding is being done.
I thought I could initially use the event Logger but it doesn't log calls to any refresh methods so then I turned my mind to the coverage logger which doesn't really help me at all.
Anyone any ideas as to how I can easily accumulate the calls to the various controls refresh methods and get some simple statistics to have a look at where all the processing effort is going?
All I can think of is to programmatically bind a "logging procedure" event to each control's refresh event and then log the results into something like a csv table for further analysis or at worst, log events by collecting information from the refresh events in the base classes for each control but that would be very long winded.
Any other ideas other than those mentioned?
Dave
[excessive quoting removed by server]
Koen, Good shout thanks!. I already had Thor Tools installed but never thought to use GoFish4 as I had some bad experiences with the very first original version but the current one looks good and stable.
Hopefully I can now track down the multiple refreshes!!
Thanks again for the heads up.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Koen Piller Sent: 06 September 2017 16:33 To: ProFox Email List profox@leafe.com Subject: Re: Event logging
Dave, 1) I would install GoFish4 this application can list you all the calls to Refresh() 2) I would comment all thisform.refresh for a starter except in the activate event of Page this usualy helps enourmously
Regards, Koen
2017-09-06 17:16 GMT+02:00 Dave Crozier DaveC@flexipol.co.uk:
Fellow Foxers, Just a little aside to late Wednesday afternoon:
I have a heavyweight data entry program in VFP written which supports one monster form with pageframes stacked inside each other each page containing various visual classes down to up to 10 levels.
This form is now showing its age as it has been added to over some 20 years and never been streamlined or optimised in any way. The main problem is that the switching from the main form pageframe onto each of the 10 tabs in the pageframe is somewhat slow running on the network and I am sure that it is all the Draw(), Paint() and refresh repeat calls that are affecting it.
So, I have decided to rip it apart and find out just where the majority of the repeat "refresh" coding is being done.
I thought I could initially use the event Logger but it doesn't log calls to any refresh methods so then I turned my mind to the coverage logger which doesn't really help me at all.
Anyone any ideas as to how I can easily accumulate the calls to the various controls refresh methods and get some simple statistics to have a look at where all the processing effort is going?
All I can think of is to programmatically bind a "logging procedure" event to each control's refresh event and then log the results into something like a csv table for further analysis or at worst, log events by collecting information from the refresh events in the base classes for each control but that would be very long winded.
Any other ideas other than those mentioned?
Dave
[excessive quoting removed by server]