Discussion:
Windows 7 + VFP9 speed problem
Mike Copeland
2011-03-02 20:02:52 UTC
Permalink
It's been a while since I've been on the list, but I've run into a real
buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be
appreciative of any and all thoughts on this issue as I'm stumped.

Application: A monolithic accounting application with a few dozen forms.
Compiled exe is 6MB
Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL
Add to the mix: DBI Technologies ctGrid OCX file (although I don't think
this is the source of the problem)
Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel
G31 Mboard

Problem: When loading a form, depending on the platform, it can take
160x as long to finish.
Task: Load 23,000 SKU #s into a combo. (details below)

Times below are very very consistent, varying only about .10 second each
run.

Scenario 1: Windows XP, compiled VFP exe application, all files local
(except MySQL data)
FAST....as in 1/2 second
Scenario 2: Windows XP, run app from source code on VFP IDE, all files
local
FAST...again, around 1/2 second
Scenario 3: Windows 7 (32 or 64 bit), source code on VFP IDE, all files
local
FAST...1/2 second

...here's the problem

Scenario 4: Windows 7, compiled exe app, all files local
SLOW....80 seconds
This happens on multiple forms that have almost
identical code.

...here's the head banger
Scenario 5: Windows 7, running compiled exe from a Linux Samba share
FAST....actually a bit faster than running on
Windows XP...less than 1/2 seconds

Windows 7 is becoming unavoidable. The solution seems to be to run the
app from the server, but many details (storage of window sizes, auto
update to new version, etc.) have been designed for local workstation
storage.

What I can not understand is why Scenario 4 is so radically different.
Any suggestions?

What I've tried:
1. Turned off UAC completely. (Started with UAC on, of course.) No effect.
2. Change ownership of the folder the files are stored in. No effect.
3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only
files No effect, although I was surprised at how fast it was (Scenario 3
above)
4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''
nowait"
5. Tried saving SELECTED data in a local DBF and loading from DBF. (This
did tweak the timing a little, like 4 seconds out of 80) Even tried
saving static data in DBF and not even involving the MySQL process.
6. Created single form with nothing but the DBI grid OCX object and
compiled as a 48Kb application. This ran fast, 1/2 second to load, but
while informative it is hardly useful.
7. I've tested and tried placing the TMPFILES location local and remote,
and let Windows manage it vs. "manual override." No change.

All in all, it seems to be pointing at a problem with the interaction
between Windows 7 and VFP9 SP2 and memory management.

I'm sure I've missed something, and I know this is a lot to read, but I
would very much appreciate any suggestions. I know of no better place to
go than here where the best and the brightest connect.

Oh, here's the code from the INIT event on the form (I've tried various
other events, and even put it in the click event of a button on the
form, no change)
Also, you'll notice there's no indication of how I'm getting the data
from MySQL. The sample below has the same speed issues described above,
but as you can see the retrieval from the MySQL server is not involved
in the timing and is actually very fast in all scenarios.
----------------------------------------------------------

MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into temp WHERE active=1 order by sku
SELECT temp
GO TOP IN temp

ttimestart=seconds()

SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN

ttimeexp=seconds()-ttimestart

MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items added.'+;
CHR(13)+'Time elapsed: '+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
-------------------------------------------------------------------------

Thanks again!
Mike Copeland
Kent Belan
2011-03-03 13:15:02 UTC
Permalink
Try using the coverage profiler. It will tell you everyline of source that
is executed and the amount of time it takes for each line.

Set coverage to test.log
Set coverage on



-----Original Message-----
From: profox-***@leafe.com [mailto:profox-***@leafe.com] On Behalf
Of Mike Copeland
Sent: Wednesday, March 02, 2011 3:03 PM
To: ***@leafe.com
Subject: Windows 7 + VFP9 speed problem

It's been a while since I've been on the list, but I've run into a real
buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be
appreciative of any and all thoughts on this issue as I'm stumped.

Application: A monolithic accounting application with a few dozen forms.
Compiled exe is 6MB
Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL Add to the
mix: DBI Technologies ctGrid OCX file (although I don't think this is the
source of the problem)
Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel
G31 Mboard

Problem: When loading a form, depending on the platform, it can take 160x as
long to finish.
Task: Load 23,000 SKU #s into a combo. (details below)

Times below are very very consistent, varying only about .10 second each
run.

Scenario 1: Windows XP, compiled VFP exe application, all files local
(except MySQL data)
FAST....as in 1/2 second Scenario 2: Windows XP, run
app from source code on VFP IDE, all files local
FAST...again, around 1/2 second Scenario 3: Windows 7
(32 or 64 bit), source code on VFP IDE, all files local
FAST...1/2 second

...here's the problem

Scenario 4: Windows 7, compiled exe app, all files local
SLOW....80 seconds
This happens on multiple forms that have almost
identical code.

...here's the head banger
Scenario 5: Windows 7, running compiled exe from a Linux Samba share
FAST....actually a bit faster than running on Windows
XP...less than 1/2 seconds

Windows 7 is becoming unavoidable. The solution seems to be to run the app
from the server, but many details (storage of window sizes, auto update to
new version, etc.) have been designed for local workstation storage.

What I can not understand is why Scenario 4 is so radically different.
Any suggestions?

What I've tried:
1. Turned off UAC completely. (Started with UAC on, of course.) No effect.
2. Change ownership of the folder the files are stored in. No effect.
3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only files
No effect, although I was surprised at how fast it was (Scenario 3
above)
4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''
nowait"
5. Tried saving SELECTED data in a local DBF and loading from DBF. (This did
tweak the timing a little, like 4 seconds out of 80) Even tried saving
static data in DBF and not even involving the MySQL process.
6. Created single form with nothing but the DBI grid OCX object and compiled
as a 48Kb application. This ran fast, 1/2 second to load, but while
informative it is hardly useful.
7. I've tested and tried placing the TMPFILES location local and remote, and
let Windows manage it vs. "manual override." No change.

All in all, it seems to be pointing at a problem with the interaction
between Windows 7 and VFP9 SP2 and memory management.

I'm sure I've missed something, and I know this is a lot to read, but I
would very much appreciate any suggestions. I know of no better place to go
than here where the best and the brightest connect.

Oh, here's the code from the INIT event on the form (I've tried various
other events, and even put it in the click event of a button on the form, no
change) Also, you'll notice there's no indication of how I'm getting the
data from MySQL. The sample below has the same speed issues described above,
but as you can see the retrieval from the MySQL server is not involved in
the timing and is actually very fast in all scenarios.
----------------------------------------------------------

MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp SELECT sku FROM skus into temp WHERE active=1
order by sku SELECT temp GO TOP IN temp

ttimestart=seconds()

SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN

ttimeexp=seconds()-ttimestart

MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items
added.'+;
CHR(13)+'Time elapsed:
'+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
-------------------------------------------------------------------------

Thanks again!
Mike Copeland




[excessive quoting removed by server]
Mike Copeland
2011-03-03 18:54:48 UTC
Permalink
Thanks Kent, I did try that. It shows that the "scan....endscan" loop
takes 1/2 second, but that was using the VFP IDE...which is an
environment that there is no problem with.

Unfortunately, I don't know of a way to run coverage profiler from the
runtime environment. Is there a way to do that?

Mike
Post by Kent Belan
Try using the coverage profiler. It will tell you everyline of source that
is executed and the amount of time it takes for each line.
Set coverage to test.log
Set coverage on
-----Original Message-----
Of Mike Copeland
Sent: Wednesday, March 02, 2011 3:03 PM
Subject: Windows 7 + VFP9 speed problem
It's been a while since I've been on the list, but I've run into a real
buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be
appreciative of any and all thoughts on this issue as I'm stumped.
Application: A monolithic accounting application with a few dozen forms.
Compiled exe is 6MB
Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL Add to the
mix: DBI Technologies ctGrid OCX file (although I don't think this is the
source of the problem)
Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel
G31 Mboard
Problem: When loading a form, depending on the platform, it can take 160x as
long to finish.
Task: Load 23,000 SKU #s into a combo. (details below)
Times below are very very consistent, varying only about .10 second each
run.
Scenario 1: Windows XP, compiled VFP exe application, all files local
(except MySQL data)
FAST....as in 1/2 second Scenario 2: Windows XP, run
app from source code on VFP IDE, all files local
FAST...again, around 1/2 second Scenario 3: Windows 7
(32 or 64 bit), source code on VFP IDE, all files local
FAST...1/2 second
...here's the problem
Scenario 4: Windows 7, compiled exe app, all files local
SLOW....80 seconds
This happens on multiple forms that have almost
identical code.
...here's the head banger
Scenario 5: Windows 7, running compiled exe from a Linux Samba share
FAST....actually a bit faster than running on Windows
XP...less than 1/2 seconds
Windows 7 is becoming unavoidable. The solution seems to be to run the app
from the server, but many details (storage of window sizes, auto update to
new version, etc.) have been designed for local workstation storage.
What I can not understand is why Scenario 4 is so radically different.
Any suggestions?
1. Turned off UAC completely. (Started with UAC on, of course.) No effect.
2. Change ownership of the folder the files are stored in. No effect.
3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only files
No effect, although I was surprised at how fast it was (Scenario 3
above)
4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''
nowait"
5. Tried saving SELECTED data in a local DBF and loading from DBF. (This did
tweak the timing a little, like 4 seconds out of 80) Even tried saving
static data in DBF and not even involving the MySQL process.
6. Created single form with nothing but the DBI grid OCX object and compiled
as a 48Kb application. This ran fast, 1/2 second to load, but while
informative it is hardly useful.
7. I've tested and tried placing the TMPFILES location local and remote, and
let Windows manage it vs. "manual override." No change.
All in all, it seems to be pointing at a problem with the interaction
between Windows 7 and VFP9 SP2 and memory management.
I'm sure I've missed something, and I know this is a lot to read, but I
would very much appreciate any suggestions. I know of no better place to go
than here where the best and the brightest connect.
Oh, here's the code from the INIT event on the form (I've tried various
other events, and even put it in the click event of a button on the form, no
change) Also, you'll notice there's no indication of how I'm getting the
data from MySQL. The sample below has the same speed issues described above,
but as you can see the retrieval from the MySQL server is not involved in
the timing and is actually very fast in all scenarios.
----------------------------------------------------------
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp SELECT sku FROM skus into temp WHERE active=1
order by sku SELECT temp GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
ttimeexp=seconds()-ttimestart
MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items added.'+;
'+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
-------------------------------------------------------------------------
Thanks again!
Mike Copeland
[excessive quoting removed by server]
Richard Kaye
2011-03-03 13:28:40 UTC
Permalink
Could be an SMB2 issue? Search the Profox archives and look for SMB2. There might be some useful info from these threads on ProFox:

Re: Strange Data Corruption Issue
Re: Any gurus out there?

--
rk

-----Original Message-----
From: profoxtech-***@leafe.com [mailto:profoxtech-***@leafe.com] On Behalf Of Mike Copeland
Sent: Wednesday, March 02, 2011 3:03 PM
To: ***@leafe.com
Subject: Windows 7 + VFP9 speed problem

It's been a while since I've been on the list, but I've run into a real buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be appreciative of any and all thoughts on this issue as I'm stumped.

Application: A monolithic accounting application with a few dozen forms.
Compiled exe is 6MB
Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL Add to the mix: DBI Technologies ctGrid OCX file (although I don't think this is the source of the problem)
Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel
G31 Mboard

Problem: When loading a form, depending on the platform, it can take 160x as long to finish.
Task: Load 23,000 SKU #s into a combo. (details below)

Times below are very very consistent, varying only about .10 second each run.

Scenario 1: Windows XP, compiled VFP exe application, all files local (except MySQL data)
FAST....as in 1/2 second Scenario 2: Windows XP, run app from source code on VFP IDE, all files local
FAST...again, around 1/2 second Scenario 3: Windows 7 (32 or 64 bit), source code on VFP IDE, all files local
FAST...1/2 second

...here's the problem

Scenario 4: Windows 7, compiled exe app, all files local
SLOW....80 seconds
This happens on multiple forms that have almost identical code.

...here's the head banger
Scenario 5: Windows 7, running compiled exe from a Linux Samba share
FAST....actually a bit faster than running on Windows XP...less than 1/2 seconds

Windows 7 is becoming unavoidable. The solution seems to be to run the app from the server, but many details (storage of window sizes, auto update to new version, etc.) have been designed for local workstation storage.

What I can not understand is why Scenario 4 is so radically different.
Any suggestions?

What I've tried:
1. Turned off UAC completely. (Started with UAC on, of course.) No effect.
2. Change ownership of the folder the files are stored in. No effect.
3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only files No effect, although I was surprised at how fast it was (Scenario 3
above)
4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''
nowait"
5. Tried saving SELECTED data in a local DBF and loading from DBF. (This did tweak the timing a little, like 4 seconds out of 80) Even tried saving static data in DBF and not even involving the MySQL process.
6. Created single form with nothing but the DBI grid OCX object and compiled as a 48Kb application. This ran fast, 1/2 second to load, but while informative it is hardly useful.
7. I've tested and tried placing the TMPFILES location local and remote, and let Windows manage it vs. "manual override." No change.

All in all, it seems to be pointing at a problem with the interaction between Windows 7 and VFP9 SP2 and memory management.

I'm sure I've missed something, and I know this is a lot to read, but I would very much appreciate any suggestions. I know of no better place to go than here where the best and the brightest connect.

Oh, here's the code from the INIT event on the form (I've tried various other events, and even put it in the click event of a button on the form, no change) Also, you'll notice there's no indication of how I'm getting the data from MySQL. The sample below has the same speed issues described above, but as you can see the retrieval from the MySQL server is not involved in the timing and is actually very fast in all scenarios.
----------------------------------------------------------

MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice') LOCAL ttimestart,ttimeexp SELECT sku FROM skus into temp WHERE active=1 order by sku SELECT temp GO TOP IN temp

ttimestart=seconds()

SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN

ttimeexp=seconds()-ttimestart

MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items added.'+;
CHR(13)+'Time elapsed: '+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
-------------------------------------------------------------------------

Thanks again!
Mike Copeland




[excessive quoting removed by server]
Mike Copeland
2011-03-03 19:02:17 UTC
Permalink
Thanks Richard.

Wouldn't the SMB1 vs. SMB2 issue come into play only with networking?

I'll admit that my description (below) is pretty muddy, but the short
version is that...

--Win7 + compiled VFP app and runtime files = slow (regardless of data
source being network or local)

--Win7 + VFP IDE-executed app = fast

--Win7 + VFP app (compiled or not) run from network drive = fast

With nothing but a single computer, no network, Win7, local DBF file,
and the VFP runtime environment, load time is slow.

It's bizarre, and defies logic...except that I do admit I do not
understand Win7 as well as I should. (I've also managed to avoid
WinVista like the plague up until now.)

Mike
Post by Richard Kaye
Re: Strange Data Corruption Issue
Re: Any gurus out there?
--
rk
-----Original Message-----
Sent: Wednesday, March 02, 2011 3:03 PM
Subject: Windows 7 + VFP9 speed problem
It's been a while since I've been on the list, but I've run into a real buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be appreciative of any and all thoughts on this issue as I'm stumped.
Application: A monolithic accounting application with a few dozen forms.
Compiled exe is 6MB
Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL Add to the mix: DBI Technologies ctGrid OCX file (although I don't think this is the source of the problem)
Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel
G31 Mboard
Problem: When loading a form, depending on the platform, it can take 160x as long to finish.
Task: Load 23,000 SKU #s into a combo. (details below)
Times below are very very consistent, varying only about .10 second each run.
Scenario 1: Windows XP, compiled VFP exe application, all files local (except MySQL data)
FAST....as in 1/2 second Scenario 2: Windows XP, run app from source code on VFP IDE, all files local
FAST...again, around 1/2 second Scenario 3: Windows 7 (32 or 64 bit), source code on VFP IDE, all files local
FAST...1/2 second
...here's the problem
Scenario 4: Windows 7, compiled exe app, all files local
SLOW....80 seconds
This happens on multiple forms that have almost identical code.
...here's the head banger
Scenario 5: Windows 7, running compiled exe from a Linux Samba share
FAST....actually a bit faster than running on Windows XP...less than 1/2 seconds
Windows 7 is becoming unavoidable. The solution seems to be to run the app from the server, but many details (storage of window sizes, auto update to new version, etc.) have been designed for local workstation storage.
What I can not understand is why Scenario 4 is so radically different.
Any suggestions?
1. Turned off UAC completely. (Started with UAC on, of course.) No effect.
2. Change ownership of the folder the files are stored in. No effect.
3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only files No effect, although I was surprised at how fast it was (Scenario 3
above)
4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''
nowait"
5. Tried saving SELECTED data in a local DBF and loading from DBF. (This did tweak the timing a little, like 4 seconds out of 80) Even tried saving static data in DBF and not even involving the MySQL process.
6. Created single form with nothing but the DBI grid OCX object and compiled as a 48Kb application. This ran fast, 1/2 second to load, but while informative it is hardly useful.
7. I've tested and tried placing the TMPFILES location local and remote, and let Windows manage it vs. "manual override." No change.
All in all, it seems to be pointing at a problem with the interaction between Windows 7 and VFP9 SP2 and memory management.
I'm sure I've missed something, and I know this is a lot to read, but I would very much appreciate any suggestions. I know of no better place to go than here where the best and the brightest connect.
Oh, here's the code from the INIT event on the form (I've tried various other events, and even put it in the click event of a button on the form, no change) Also, you'll notice there's no indication of how I'm getting the data from MySQL. The sample below has the same speed issues described above, but as you can see the retrieval from the MySQL server is not involved in the timing and is actually very fast in all scenarios.
----------------------------------------------------------
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice') LOCAL ttimestart,ttimeexp SELECT sku FROM skus into temp WHERE active=1 order by sku SELECT temp GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
ttimeexp=seconds()-ttimestart
MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items added.'+;
CHR(13)+'Time elapsed: '+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
-------------------------------------------------------------------------
Thanks again!
Mike Copeland
[excessive quoting removed by server]
Sytze de Boer
2011-03-03 19:08:44 UTC
Permalink
Please excuse my ignorance (once again)
Am I correct that
1 A compile vfp app + runtime files is a EXE file that you have compiled +
vfpr.dll and vfprune.dll
2 What is a VFP IDE-executed app?
3 and how would you run your 3rd option ?

S
Post by Mike Copeland
Thanks Richard.
Wouldn't the SMB1 vs. SMB2 issue come into play only with networking?
I'll admit that my description (below) is pretty muddy, but the short
version is that...
--Win7 + compiled VFP app and runtime files = slow (regardless of data
source being network or local)
--Win7 + VFP IDE-executed app = fast
--Win7 + VFP app (compiled or not) run from network drive = fast
With nothing but a single computer, no network, Win7, local DBF file,
and the VFP runtime environment, load time is slow.
It's bizarre, and defies logic...except that I do admit I do not
understand Win7 as well as I should. (I've also managed to avoid
WinVista like the plague up until now.)
Mike
Post by Richard Kaye
Could be an SMB2 issue? Search the Profox archives and look for SMB2.
Re: Strange Data Corruption Issue
Re: Any gurus out there?
--
rk
-----Original Message-----
On Behalf Of Mike Copeland
Post by Richard Kaye
Sent: Wednesday, March 02, 2011 3:03 PM
Subject: Windows 7 + VFP9 speed problem
It's been a while since I've been on the list, but I've run into a real
buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be
appreciative of any and all thoughts on this issue as I'm stumped.
Post by Richard Kaye
Application: A monolithic accounting application with a few dozen forms.
Compiled exe is 6MB
Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL Add to
the mix: DBI Technologies ctGrid OCX file (although I don't think this is
the source of the problem)
Post by Richard Kaye
Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel
G31 Mboard
Problem: When loading a form, depending on the platform, it can take 160x
as long to finish.
Post by Richard Kaye
Task: Load 23,000 SKU #s into a combo. (details below)
Times below are very very consistent, varying only about .10 second each
run.
Post by Richard Kaye
Scenario 1: Windows XP, compiled VFP exe application, all files local
(except MySQL data)
Post by Richard Kaye
FAST....as in 1/2 second Scenario 2: Windows XP,
run app from source code on VFP IDE, all files local
Post by Richard Kaye
FAST...again, around 1/2 second Scenario 3: Windows
7 (32 or 64 bit), source code on VFP IDE, all files local
Post by Richard Kaye
FAST...1/2 second
...here's the problem
Scenario 4: Windows 7, compiled exe app, all files local
SLOW....80 seconds
This happens on multiple forms that have almost
identical code.
Post by Richard Kaye
...here's the head banger
Scenario 5: Windows 7, running compiled exe from a Linux Samba share
FAST....actually a bit faster than running on
Windows XP...less than 1/2 seconds
Post by Richard Kaye
Windows 7 is becoming unavoidable. The solution seems to be to run the
app from the server, but many details (storage of window sizes, auto update
to new version, etc.) have been designed for local workstation storage.
Post by Richard Kaye
What I can not understand is why Scenario 4 is so radically different.
Any suggestions?
1. Turned off UAC completely. (Started with UAC on, of course.) No
effect.
Post by Richard Kaye
2. Change ownership of the folder the files are stored in. No effect.
3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only
files No effect, although I was surprised at how fast it was (Scenario 3
Post by Richard Kaye
above)
4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''
nowait"
5. Tried saving SELECTED data in a local DBF and loading from DBF. (This
did tweak the timing a little, like 4 seconds out of 80) Even tried saving
static data in DBF and not even involving the MySQL process.
Post by Richard Kaye
6. Created single form with nothing but the DBI grid OCX object and
compiled as a 48Kb application. This ran fast, 1/2 second to load, but while
informative it is hardly useful.
Post by Richard Kaye
7. I've tested and tried placing the TMPFILES location local and remote,
and let Windows manage it vs. "manual override." No change.
Post by Richard Kaye
All in all, it seems to be pointing at a problem with the interaction
between Windows 7 and VFP9 SP2 and memory management.
Post by Richard Kaye
I'm sure I've missed something, and I know this is a lot to read, but I
would very much appreciate any suggestions. I know of no better place to go
than here where the best and the brightest connect.
Post by Richard Kaye
Oh, here's the code from the INIT event on the form (I've tried various
other events, and even put it in the click event of a button on the form, no
change) Also, you'll notice there's no indication of how I'm getting the
data from MySQL. The sample below has the same speed issues described above,
but as you can see the retrieval from the MySQL server is not involved in
the timing and is actually very fast in all scenarios.
Post by Richard Kaye
----------------------------------------------------------
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp SELECT sku FROM skus into temp WHERE active=1
order by sku SELECT temp GO TOP IN temp
Post by Richard Kaye
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
ttimeexp=seconds()-ttimestart
MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items
added.'+;
'+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
Post by Richard Kaye
-------------------------------------------------------------------------
Thanks again!
Mike Copeland
[excessive quoting removed by server]
Mike Copeland
2011-03-03 19:55:45 UTC
Permalink
Excellent questions! I believe you are focused on the true problem...

1. Yes, correct. compiled EXE VFP app + runtime vfpr..dll and
vfprune.dll RUNS SLOW

2. Install VFP9 complete from DVD, update it with SP2, load source code,
run. RUNS FAST

3. a) install OCX files on local drive.
b) install run time files on local drive (or IDE as in #2)
c) move compiled EXE VFP app to a folder on a network server. In my
case my servers are Linux with Samba shares.
RUNS FAST

Option #3 above is the way I'm going to go, but it means that my app
will not be able to be deployed on Win7 systems that access the data via
the Internet (back to the MySQL server for data.) This Internet option
was a fantastic benefit and works really well...on every Windows except
Win7. But, if running from a server (#3) is my only option at this
point, at least it allows me to deploy some new workstations at a
client's site next week without mud on my face.

Thanks!

Mike
Post by Sytze de Boer
Please excuse my ignorance (once again)
Am I correct that
1 A compile vfp app + runtime files is a EXE file that you have compiled +
vfpr.dll and vfprune.dll
2 What is a VFP IDE-executed app?
3 and how would you run your 3rd option ?
S
Post by Mike Copeland
Thanks Richard.
Wouldn't the SMB1 vs. SMB2 issue come into play only with networking?
I'll admit that my description (below) is pretty muddy, but the short
version is that...
--Win7 + compiled VFP app and runtime files = slow (regardless of data
source being network or local)
--Win7 + VFP IDE-executed app = fast
--Win7 + VFP app (compiled or not) run from network drive = fast
With nothing but a single computer, no network, Win7, local DBF file,
and the VFP runtime environment, load time is slow.
It's bizarre, and defies logic...except that I do admit I do not
understand Win7 as well as I should. (I've also managed to avoid
WinVista like the plague up until now.)
Mike
Post by Richard Kaye
Could be an SMB2 issue? Search the Profox archives and look for SMB2.
Re: Strange Data Corruption Issue
Re: Any gurus out there?
--
rk
-----Original Message-----
On Behalf Of Mike Copeland
Post by Richard Kaye
Sent: Wednesday, March 02, 2011 3:03 PM
Subject: Windows 7 + VFP9 speed problem
It's been a while since I've been on the list, but I've run into a real
buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be
appreciative of any and all thoughts on this issue as I'm stumped.
Post by Richard Kaye
Application: A monolithic accounting application with a few dozen forms.
Compiled exe is 6MB
Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL Add to
the mix: DBI Technologies ctGrid OCX file (although I don't think this is
the source of the problem)
Post by Richard Kaye
Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel
G31 Mboard
Problem: When loading a form, depending on the platform, it can take 160x
as long to finish.
Post by Richard Kaye
Task: Load 23,000 SKU #s into a combo. (details below)
Times below are very very consistent, varying only about .10 second each
run.
Post by Richard Kaye
Scenario 1: Windows XP, compiled VFP exe application, all files local
(except MySQL data)
Post by Richard Kaye
FAST....as in 1/2 second Scenario 2: Windows XP,
run app from source code on VFP IDE, all files local
Post by Richard Kaye
FAST...again, around 1/2 second Scenario 3: Windows
7 (32 or 64 bit), source code on VFP IDE, all files local
Post by Richard Kaye
FAST...1/2 second
...here's the problem
Scenario 4: Windows 7, compiled exe app, all files local
SLOW....80 seconds
This happens on multiple forms that have almost
identical code.
Post by Richard Kaye
...here's the head banger
Scenario 5: Windows 7, running compiled exe from a Linux Samba share
FAST....actually a bit faster than running on
Windows XP...less than 1/2 seconds
Post by Richard Kaye
Windows 7 is becoming unavoidable. The solution seems to be to run the
app from the server, but many details (storage of window sizes, auto update
to new version, etc.) have been designed for local workstation storage.
Post by Richard Kaye
What I can not understand is why Scenario 4 is so radically different.
Any suggestions?
1. Turned off UAC completely. (Started with UAC on, of course.) No
effect.
Post by Richard Kaye
2. Change ownership of the folder the files are stored in. No effect.
3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only
files No effect, although I was surprised at how fast it was (Scenario 3
Post by Richard Kaye
above)
4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''
nowait"
5. Tried saving SELECTED data in a local DBF and loading from DBF. (This
did tweak the timing a little, like 4 seconds out of 80) Even tried saving
static data in DBF and not even involving the MySQL process.
Post by Richard Kaye
6. Created single form with nothing but the DBI grid OCX object and
compiled as a 48Kb application. This ran fast, 1/2 second to load, but while
informative it is hardly useful.
Post by Richard Kaye
7. I've tested and tried placing the TMPFILES location local and remote,
and let Windows manage it vs. "manual override." No change.
Post by Richard Kaye
All in all, it seems to be pointing at a problem with the interaction
between Windows 7 and VFP9 SP2 and memory management.
Post by Richard Kaye
I'm sure I've missed something, and I know this is a lot to read, but I
would very much appreciate any suggestions. I know of no better place to go
than here where the best and the brightest connect.
Post by Richard Kaye
Oh, here's the code from the INIT event on the form (I've tried various
other events, and even put it in the click event of a button on the form, no
change) Also, you'll notice there's no indication of how I'm getting the
data from MySQL. The sample below has the same speed issues described above,
but as you can see the retrieval from the MySQL server is not involved in
the timing and is actually very fast in all scenarios.
Post by Richard Kaye
----------------------------------------------------------
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp SELECT sku FROM skus into temp WHERE active=1
order by sku SELECT temp GO TOP IN temp
Post by Richard Kaye
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
ttimeexp=seconds()-ttimestart
MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items
added.'+;
'+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
Post by Richard Kaye
-------------------------------------------------------------------------
Thanks again!
Mike Copeland
[excessive quoting removed by server]
MB Software Solutions, LLC
2011-03-03 13:52:46 UTC
Permalink
On 3/2/2011 3:02 PM, Mike Copeland wrote:
<snipped>
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into temp WHERE active=1 order by sku
SELECT temp
GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Mike,
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into CURSOR temp WHERE active=1 order by sku
SELECT temp
LOCATE
ttimestart=seconds()
SCAN
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Not sure if that'll make much difference, but it's known that LOCATE is
quicker than GO TOP. Also, your SCAN loop doesn't need the WHILE !EOF
clause.

My comment on the design is that I wouldn't do 23,000 items in a combo,
but I guess you can't change that now?
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
Dan Covill
2011-03-03 17:59:03 UTC
Permalink
Mike:

I agree with Michael Babcock's suggestions - use a cursor and use LOCATE
instead of GO TOP. But that doesn't seem to explain the difference in
your four scenarios.

IIRC, the one that fails is the compiled app on a local VFP 7. Which
leads to a few questions:
a) Is this one system only or several?
b) What is the virtual memory setup? No swap file or too small to start
could do something like this.
c) Is write caching turned off on the local drive?

Seems to me that it has to be something in the loop. I like MB's
thought about getting rid of the NOT EOF().

Dan Covill
Post by MB Software Solutions, LLC
<snipped>
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into temp WHERE active=1 order by sku
SELECT temp
GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Mike,
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into CURSOR temp WHERE active=1 order by sku
SELECT temp
LOCATE
ttimestart=seconds()
SCAN
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Not sure if that'll make much difference, but it's known that LOCATE is
quicker than GO TOP. Also, your SCAN loop doesn't need the WHILE !EOF
clause.
My comment on the design is that I wouldn't do 23,000 items in a combo,
but I guess you can't change that now?
Mike Copeland
2011-03-03 20:17:11 UTC
Permalink
Dan,

Again, excellent questions!

a) I've built three systems and see the same results consistently.
Win7 32 bit
Win7 64 bit
two different Intel Mboards, G31 and an older one....I think it's a
965. All with built-in NICs.
I did try using a different NIC on the 965 system.
I always use Seagate Hdrives, but different models as technology
advances.

b) I haven't done anything with regards to virt memory....I did notice
that if I set the TMPFILES parameter, and checked the location of the
cursors with DBF() after they were created and before the combo load
routine ran, I could get Windows+VFP to "put it where I wanted it to"
but it didn't make any difference in speed.
I also noticed that by looking in the temp folder while the program
was paused
messagebox('File location: '+dbf('temp'),0,'Notice')
that Windows never created any file in the temp folder even though
VFP reported it as being there along with the cursor's file name. Not
unusual. The cursor isn't really that big.

c) You got me here. Tell me how to do that and I'll try it! But it seems
odd that running the EXE from a network drive is fast. I mean, I THINK
that the local drive is used for cursors and caching and such when
running the EXE from a network drive, so why would it be different????

Personally, I don't like finding funky anomalies.

And, I hope ya'll don't think I'm just shooting down anything that is
suggested. It really does help to hear your suggestions! That's why my
original post was so long....I was trying to eliminate irrelevant
factors. At least they seem irrelevant to me....but maybe not.

Thanks again Dan!

Mike
Post by Dan Covill
I agree with Michael Babcock's suggestions - use a cursor and use LOCATE
instead of GO TOP. But that doesn't seem to explain the difference in
your four scenarios.
IIRC, the one that fails is the compiled app on a local VFP 7. Which
a) Is this one system only or several?
b) What is the virtual memory setup? No swap file or too small to start
could do something like this.
c) Is write caching turned off on the local drive?
Seems to me that it has to be something in the loop. I like MB's
thought about getting rid of the NOT EOF().
Dan Covill
Post by MB Software Solutions, LLC
<snipped>
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into temp WHERE active=1 order by sku
SELECT temp
GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Mike,
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into CURSOR temp WHERE active=1 order by sku
SELECT temp
LOCATE
ttimestart=seconds()
SCAN
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Not sure if that'll make much difference, but it's known that LOCATE is
quicker than GO TOP. Also, your SCAN loop doesn't need the WHILE !EOF
clause.
My comment on the design is that I wouldn't do 23,000 items in a combo,
but I guess you can't change that now?
[excessive quoting removed by server]
Dan Covill
2011-03-03 20:58:06 UTC
Permalink
(I asked if write caching was turned off.)
Post by Mike Copeland
c) You got me here. Tell me how to do that and I'll try it! But it seems
odd that running the EXE from a network drive is fast. I mean, I THINK
that the local drive is used for cursors and caching and such when
running the EXE from a network drive, so why would it be different????
Easy. In Win7, "Computer", right click on the drive.
Click on 'Properties'
Select the 'Hardware' tab. Click the 'Properties' button.
Select the 'Policies' tab. There are two toggle buttons.
UNselect the 'Better Performance' choice.

Note: I don't really believe this is the problem, but it's a cheap
thing to check.

The symptoms still sound a lot like memory 'thrashing' due to allocating
temporary areas for the method that adds to the listbox.
That means the swapfile. Make sure that
a) The swapfile has a reasonable size.
b) The swapfile size is fixed. Do NOT 'let Windows manage it'.

Your loop is
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
I don't see any .addcomboitem() method in a grid, so I guess this is a
custom method that deals with a column in the grid. My guess is that
something about the way this is coded, combined with some change in the
way Windows 7 handles the memory allocation, may be causing the problem.
What does this method do, exactly?

Dan Covill
Mike Copeland
2011-03-03 21:20:45 UTC
Permalink
Well, heck, that IS easy!

But, no difference. And, because Windows just likes to have its ears
scratched, I rebooted after changing the cache setting before I tested
my app.

Okay, overload of the term GRID.

What I'm using is NOT a VFP Grid. It's an OCX tool from DBI called
ctGrid. It has a lot of nifty eye candy and benefits over the VFP native
objects. Plus, once you get your head around it, it's pretty easy to
use. And after using their code for over 10 years, I've learned the
pitfalls and other traps to avoid. Until this, I've not run into
anything that hasn't been fixable. If anyone wants to see what it looks
like/does, I'd be happy to send screen snaps. POS/inventory control apps
are sooo exciting!!! zzzzzzz

What the AddComboItem does is load data into the ctGrid's memory pool so
it can manage the list/array. Then, as the user types in a cell on the
grid, it auto-displays a dropdown list with matching SKUs. A simple
incremental search. Very fast, very solid. As I understand it, they
write everything in Visual C+ and the company, DBI has been outstanding
to support problems. It's just that this time I've run into something
that really doesn't look like their problem.

But, I'm beginning to wonder...what if I used a VFP Grid with a
combo...I've already spent more time trying to figure this out than it
would have taken to replace the grid.

Thanks Dan!

Mike
Post by Dan Covill
(I asked if write caching was turned off.)
Post by Mike Copeland
c) You got me here. Tell me how to do that and I'll try it! But it seems
odd that running the EXE from a network drive is fast. I mean, I THINK
that the local drive is used for cursors and caching and such when
running the EXE from a network drive, so why would it be different????
Easy. In Win7, "Computer", right click on the drive.
Click on 'Properties'
Select the 'Hardware' tab. Click the 'Properties' button.
Select the 'Policies' tab. There are two toggle buttons.
UNselect the 'Better Performance' choice.
Note: I don't really believe this is the problem, but it's a cheap
thing to check.
The symptoms still sound a lot like memory 'thrashing' due to allocating
temporary areas for the method that adds to the listbox.
That means the swapfile. Make sure that
a) The swapfile has a reasonable size.
b) The swapfile size is fixed. Do NOT 'let Windows manage it'.
Your loop is
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
I don't see any .addcomboitem() method in a grid, so I guess this is a
custom method that deals with a column in the grid. My guess is that
something about the way this is coded, combined with some change in the
way Windows 7 handles the memory allocation, may be causing the problem.
What does this method do, exactly?
Dan Covill
[excessive quoting removed by server]
Mike Copeland
2011-03-03 19:09:59 UTC
Permalink
Thanks Mike! I'll try that. Hell, I'll try anything.

The "WHILE !EOF('temp')" is an old habit that makes it easier for me to
read the code and grasp what is going on.

As for the 23,000 items...I'm in an odd situation with a client that
involves both technical-computer issues and my competency, and political
issues with a new co-owner. The new co-owner is, for want of a better
term, frothing at the bit to dump my app and me and bring in his "guy."

I've approached the fact that having 23,000 SKUs available at all times
is way over the top (they could easily get by with 7,000), and the code
does run faster with fewer SKUs in the pie, but using that as the
solution is going to be used as another brick in the wall in the
political situation.

And, I have to confess that it just rubs me wrong that my app is running
great until Windows 7 becomes an issue. Suddenly I'm thinking like a
curmudgeon...."Why can't we all go back to Windows NT?"

I'll let you know about the impact from the code tweaks, if any. Thanks
again!

Mike
Post by MB Software Solutions, LLC
<snipped>
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into temp WHERE active=1 order by sku
SELECT temp
GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Mike,
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into CURSOR temp WHERE active=1 order by sku
SELECT temp
LOCATE
ttimestart=seconds()
SCAN
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Not sure if that'll make much difference, but it's known that LOCATE is
quicker than GO TOP. Also, your SCAN loop doesn't need the WHILE !EOF
clause.
My comment on the design is that I wouldn't do 23,000 items in a combo,
but I guess you can't change that now?
Frank Cazabon
2011-03-03 19:32:04 UTC
Permalink
Hi Mike,

loading 23,000 SKUs isn't the problem, but loading them in a combo
box/drop down list is what the others' comments were about. I believe
the interface guidelines are that a combo is for a relatively few
choices (less than 100 or 200 is the maximum I've heard mentioned). You
can use a grid with an incremental search which will give the end user a
better experience for that amount of data. I only ever use a combo with
maximum 10 choices.

Frank.

Frank Cazabon
Samaan Systems Ltd. - Developing Solutions
www.SamaanSystems.com

Referrals are important to us.
If you know of anyone who would benefit from our services, please contact me. We would appreciate the opportunity to work with them.
Post by Mike Copeland
Thanks Mike! I'll try that. Hell, I'll try anything.
The "WHILE !EOF('temp')" is an old habit that makes it easier for me to
read the code and grasp what is going on.
As for the 23,000 items...I'm in an odd situation with a client that
involves both technical-computer issues and my competency, and political
issues with a new co-owner. The new co-owner is, for want of a better
term, frothing at the bit to dump my app and me and bring in his "guy."
I've approached the fact that having 23,000 SKUs available at all times
is way over the top (they could easily get by with 7,000), and the code
does run faster with fewer SKUs in the pie, but using that as the
solution is going to be used as another brick in the wall in the
political situation.
And, I have to confess that it just rubs me wrong that my app is running
great until Windows 7 becomes an issue. Suddenly I'm thinking like a
curmudgeon...."Why can't we all go back to Windows NT?"
I'll let you know about the impact from the code tweaks, if any. Thanks
again!
Mike
Post by MB Software Solutions, LLC
<snipped>
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into temp WHERE active=1 order by sku
SELECT temp
GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Mike,
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into CURSOR temp WHERE active=1 order by sku
SELECT temp
LOCATE
ttimestart=seconds()
SCAN
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Not sure if that'll make much difference, but it's known that LOCATE is
quicker than GO TOP. Also, your SCAN loop doesn't need the WHILE !EOF
clause.
My comment on the design is that I wouldn't do 23,000 items in a combo,
but I guess you can't change that now?
[excessive quoting removed by server]
Mike Copeland
2011-03-03 20:36:34 UTC
Permalink
Frank,

I'm in total agreement, but the way that DBI's ctGrid loads its combo is
a little different.

Essentially, you load all the possible data into the ctGrid memory
manager, and then the "drop down" acts like an incremental search. My
clients love it. Once the data is loaded into ctGrid, it's extremely
fast. Heck, on all platforms except Win7+VFP runtime it's extremely fast
in all regards.

I hadn't mentioned it, but I have another DBI OCX that I'm using on
another form, the SKU Editor form, that loads the same list of 23,000
SKUs and it....ready for this?....is slow. Same performance as the ctGrid.

I agree with you that needing to load 23,000 SKUs into a combo is over
the top, and that will be addressed soon with my client, but for now,
why would the performance be so dramatically different just because the
OS changes is my question. (Yeah, I know, at some point you have to get
past the problem and accept a work-around.)

Thanks for grok'ing this!

Mike
Post by Frank Cazabon
Hi Mike,
loading 23,000 SKUs isn't the problem, but loading them in a combo
box/drop down list is what the others' comments were about. I believe
the interface guidelines are that a combo is for a relatively few
choices (less than 100 or 200 is the maximum I've heard mentioned). You
can use a grid with an incremental search which will give the end user a
better experience for that amount of data. I only ever use a combo with
maximum 10 choices.
Frank.
Frank Cazabon
Samaan Systems Ltd. - Developing Solutions
www.SamaanSystems.com
Referrals are important to us.
If you know of anyone who would benefit from our services, please contact me. We would appreciate the opportunity to work with them.
Post by Mike Copeland
Thanks Mike! I'll try that. Hell, I'll try anything.
The "WHILE !EOF('temp')" is an old habit that makes it easier for me to
read the code and grasp what is going on.
As for the 23,000 items...I'm in an odd situation with a client that
involves both technical-computer issues and my competency, and political
issues with a new co-owner. The new co-owner is, for want of a better
term, frothing at the bit to dump my app and me and bring in his "guy."
I've approached the fact that having 23,000 SKUs available at all times
is way over the top (they could easily get by with 7,000), and the code
does run faster with fewer SKUs in the pie, but using that as the
solution is going to be used as another brick in the wall in the
political situation.
And, I have to confess that it just rubs me wrong that my app is running
great until Windows 7 becomes an issue. Suddenly I'm thinking like a
curmudgeon...."Why can't we all go back to Windows NT?"
I'll let you know about the impact from the code tweaks, if any. Thanks
again!
Mike
Post by MB Software Solutions, LLC
<snipped>
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into temp WHERE active=1 order by sku
SELECT temp
GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Mike,
Post by Mike Copeland
MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into CURSOR temp WHERE active=1 order by sku
SELECT temp
LOCATE
ttimestart=seconds()
SCAN
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
Not sure if that'll make much difference, but it's known that LOCATE is
quicker than GO TOP. Also, your SCAN loop doesn't need the WHILE !EOF
clause.
My comment on the design is that I wouldn't do 23,000 items in a combo,
but I guess you can't change that now?
[excessive quoting removed by server]
MB Software Solutions, LLC
2011-03-03 21:18:55 UTC
Permalink
Post by Mike Copeland
Thanks Mike! I'll try that. Hell, I'll try anything.
The "WHILE !EOF('temp')" is an old habit that makes it easier for me to
read the code and grasp what is going on.
As for the 23,000 items...I'm in an odd situation with a client that
involves both technical-computer issues and my competency, and political
issues with a new co-owner. The new co-owner is, for want of a better
term, frothing at the bit to dump my app and me and bring in his "guy."
I've approached the fact that having 23,000 SKUs available at all times
is way over the top (they could easily get by with 7,000), and the code
does run faster with fewer SKUs in the pie, but using that as the
solution is going to be used as another brick in the wall in the
political situation.
And, I have to confess that it just rubs me wrong that my app is running
great until Windows 7 becomes an issue. Suddenly I'm thinking like a
curmudgeon...."Why can't we all go back to Windows NT?"
I'll let you know about the impact from the code tweaks, if any. Thanks
again!
Mike
You might try a simple textbox that checks the SKU entered in the Valid
event, and if an exact match is not found, then show a list of partial
matches in a pop-up form and let him pick there from a much-lesser
populated, focused list. Then, back on the first screen, show the part
description in a label next to the valid SKU chosen.

Just a thought.

Good luck!
--Mike
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
Tracy Pearson
2011-03-03 14:41:49 UTC
Permalink
Mike Copeland wrote on 2011-03-02:
<snip>
Post by Mike Copeland
Oh, here's the code from the INIT event on the form (I've tried various
other events, and even put it in the click event of a button on the
form, no change) Also, you'll notice there's no indication of how I'm
getting the data from MySQL. The sample below has the same speed issues
described above, but as you can see the retrieval from the MySQL server
is not involved in the timing and is actually very fast in all
scenarios. ----------------------------------------------------------
MESSAGEBOX('Starting to load Grid. Click OK to
start...',0+64,'Notice') LOCAL ttimestart,ttimeexp SELECT sku FROM
skus into temp WHERE active=1 order by sku SELECT temp GO TOP IN temp
ttimestart=seconds()
SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN
ttimeexp=seconds()-ttimestart
MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items added.'+;
'+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
---------------------------------------------------------------------- -

Mike,

Move the code to a new method on the form. Then call it from the
ctGrid.FirstDraw event.
See if turning off the fancy Windows 7 graphical themes with SYS(2700,0).

Tracy Pearson
PowerChurch Software
Mike Copeland
2011-03-03 19:25:58 UTC
Permalink
Tracy,

Many thanks!

Yes, I tried the Firstdraw event as that is a pretty common issue with
DBI components. And, I was surprised that it made no difference at all.
I also tried a few other form events and ctGrid events...I forget which
ones now because it was in the wee hours a few days ago. No effect.

I'll try dumping the eye candy, although that's going to negatively
impact my satisfaction in using my computer! (Don't you realize how
important glowing buttons and transparent borders are!!!!)

Thanks again! I'll report any improvements.

Mike
Post by Tracy Pearson
Mike,
Move the code to a new method on the form. Then call it from the
ctGrid.FirstDraw event.
See if turning off the fancy Windows 7 graphical themes with SYS(2700,0).
Tracy Pearson
PowerChurch Software
Tracy Pearson
2011-03-03 19:52:10 UTC
Permalink
Post by Mike Copeland
Tracy,
Many thanks!
Yes, I tried the Firstdraw event as that is a pretty common issue with
DBI components. And, I was surprised that it made no difference at all.
I also tried a few other form events and ctGrid events...I forget
which ones now because it was in the wee hours a few days ago. No effect.
I'll try dumping the eye candy, although that's going to negatively
impact my satisfaction in using my computer! (Don't you realize how
important glowing buttons and transparent borders are!!!!)
Thanks again! I'll report any improvements.
Mike
Post by Tracy Pearson
Mike,
Move the code to a new method on the form. Then call it from the
ctGrid.FirstDraw event. See if turning off the fancy Windows 7
graphical themes with SYS(2700,0).
Tracy Pearson
PowerChurch Software
Mike,

I'm told time and again about eye candy. I'm suggesting a test to see if the
speed is due to the eye candy.

Explain the full structure of the form this is on. Is the ctGrid object on a
page in a pageframe, in a container, are other ActiveX controls on the form,
is there other code associated in events of the ctGrid that might be
redrawing the control as it is getting loaded?
Post by Mike Copeland
From what I've seen the IDE handles memory and UI things a little
differently than the IDE.

Open the Debug window, then launch the form on the Windows 7. You'll
probably see it crawl and take over 2 minutes.



Tracy Pearson
PowerChurch Software
Mike Copeland
2011-03-03 21:01:02 UTC
Permalink
Tracy,

Hey, I'm no fan of dancing bears or FLASH! Wait, those are mutually
dependent...If you want to totally screw up the usefulness of a web
page, just start adding flash...

Okay, the form is actually one of three that are similar but have subtle
differences. I'd be happy to send you a screen snap off list. Heck, I'll
even set up a remote access to the machine I'm testing on!

In the app, there is a QUOTE form, an ORDER form, and a SALE form.
Obviously to handle the three steps in a sales scenario. There will also
be a CREDIT, aka RETURN form, but that's irrelevant. All the forms are
similar, but with different requirements, therefore the different forms.
In a previous incarnation I had one form that was tweaked and modified
on the fly depending on the function...pain in the rear!

The forms have no pageframes, the ctGrid is sitting in the center of the
form, on the form. Hence the code "thisform.ctGrid.addComboItem()

The only other OCX on the ORDER form is ctTOOLBAR, also from DBI. BUT,
The QUOTE form does not use the ctTOOLBAR OCX, yet. And the QUOTE form
is also slow to load.

Also, I am seeing the same slow load with the ctMEDIT OCX control on the
SKU Edit form, which also loads the same 23,000 SKUs in the INIT event
of the form. Same speed...78 to 80 seconds.

Important to note that my timing only involves the combo load...not the
data manipulation or retrieval.

Observation: I think it's relevant that I do see SLOWER speeds when
attempting the same routine repeatedly. The first time, slow or fast is
X and the second and subsequent executions are X+.
Explanation: Open the ORDER form on the slow setup. Takes 78 seconds.
Close, and then re-open the ORDER form on the
slow setup. Takes 80 seconds.
Close, reopen, over and over and it takes 80
seconds each time.

Open the ORDER form on the fast setup. Takes
.52 seconds.
Close, and then re-open the ORDER form on the
fast setup. Takes .57 seconds.
And so on.

Again, seems to be a memory management issue.

There is code in other events of the ctGRID...
AfterCellExit
AfterCellWrite
BeforeCellEdit
CellDblClick
CheckClick
FirstDraw
LostFocus
RightClick

I would welcome any suggestions on where to locate, or otherwise
reconfigure the event coding. I'm not aware of any of the above events
getting their toes stomped by using the AddComboItem method.

I've been in touch with DBI, but, understandably, they can't recreate
the problem and when I created a simple form with nothing but the grid
and a DBF file to load from, it was fast (in the SLOW scenario.)
Obviously this means that the form has to be part of a larger
application to cause the gagging to happen.

I opened Debug in the VFP IDE on the Win7 machine, clicked to load the
form, and it finished about half way through this email. Slow is not the
word for the thrill of watching your code execute in the debug tracer
window!

Since I have a machine that can be totally hosed if necessary, I have
even been tempted to copy some of the older versions of the Visual C
runtime files from Windows XP to Win7. Any thoughts on that?

Mike
Post by Tracy Pearson
Post by Mike Copeland
Tracy,
Many thanks!
Yes, I tried the Firstdraw event as that is a pretty common issue with
DBI components. And, I was surprised that it made no difference at all.
I also tried a few other form events and ctGrid events...I forget
which ones now because it was in the wee hours a few days ago. No effect.
I'll try dumping the eye candy, although that's going to negatively
impact my satisfaction in using my computer! (Don't you realize how
important glowing buttons and transparent borders are!!!!)
Thanks again! I'll report any improvements.
Mike
Post by Tracy Pearson
Mike,
Move the code to a new method on the form. Then call it from the
ctGrid.FirstDraw event. See if turning off the fancy Windows 7
graphical themes with SYS(2700,0).
Tracy Pearson
PowerChurch Software
Mike,
I'm told time and again about eye candy. I'm suggesting a test to see if the
speed is due to the eye candy.
Explain the full structure of the form this is on. Is the ctGrid object on a
page in a pageframe, in a container, are other ActiveX controls on the form,
is there other code associated in events of the ctGrid that might be
redrawing the control as it is getting loaded?
Post by Mike Copeland
From what I've seen the IDE handles memory and UI things a little
differently than the IDE.
Open the Debug window, then launch the form on the Windows 7. You'll
probably see it crawl and take over 2 minutes.
Tracy Pearson
PowerChurch Software
[excessive quoting removed by server]
Tracy Pearson
2011-03-03 21:36:57 UTC
Permalink
Mike,

Have you changed appearance settings on the control that you didn't set in
the sample exe?
No change with Theme's disabled? Something is nagging me about the control
and display causing the lag.

Do any of these places have code that might redraw the control? Can you
return out of each of these places if a form property is set, which you set
prior to your AddComboItem loop?
Post by Mike Copeland
There is code in other events of the ctGRID...
AfterCellExit
AfterCellWrite
BeforeCellEdit
CellDblClick
CheckClick
FirstDraw
LostFocus
RightClick
Tracy Pearson
PowerChurch Software
Mike Copeland
2011-03-03 22:42:24 UTC
Permalink
Tracy,

I may be misunderstanding your focus, but the AddComboItem loop is in
the Init of the form, before the form ever displays. Once the form
displays, there are no speed issues and the combo is never loaded
again....until a new instance of the form is called for.

The code in each of the ctGrid methods and events have to do with
recalculating tax (calling a form method) popping up a messagebox if
they enter an unknown "off the list" SKU, etc. None of them cause the
ctGrid to redraw, adjust, or be modified in any way, either on purpose
or not-on purpose.

I turned off Windows Themes in the Win7 Control Panel>Personalization,
no change.

Set sys(2700,1) in the beginning of my MAIN.PRG, and it actually
increased the times, on both the FAST and the SLOW scenarios.

Bizarre!

Mike
Post by Tracy Pearson
Mike,
Have you changed appearance settings on the control that you didn't set in
the sample exe?
No change with Theme's disabled? Something is nagging me about the control
and display causing the lag.
Do any of these places have code that might redraw the control? Can you
return out of each of these places if a form property is set, which you set
prior to your AddComboItem loop?
Post by Mike Copeland
There is code in other events of the ctGRID...
AfterCellExit
AfterCellWrite
BeforeCellEdit
CellDblClick
CheckClick
FirstDraw
LostFocus
RightClick
Tracy Pearson
PowerChurch Software
[excessive quoting removed by server]
Tracy Pearson
2011-03-03 23:17:06 UTC
Permalink
Post by Mike Copeland
Tracy,
I may be misunderstanding your focus, but the AddComboItem loop is in
the Init of the form, before the form ever displays. Once the form
displays, there are no speed issues and the combo is never loaded
again....until a new instance of the form is called for.
The code in each of the ctGrid methods and events have to do with
recalculating tax (calling a form method) popping up a messagebox if
they enter an unknown "off the list" SKU, etc. None of them cause the
ctGrid to redraw, adjust, or be modified in any way, either on purpose
or not-on purpose.
I turned off Windows Themes in the Win7 Control Panel>Personalization,
no change.
Set sys(2700,1) in the beginning of my MAIN.PRG, and it actually
increased the times, on both the FAST and the SLOW scenarios.
Bizarre!
Mike
Mike,

No, I think you understood where I was heading. It isn't making sense. There
was an odd behavior seen once in my application that I've not been able to
take the time to track down. It is related to VFP 9 SP 2 runtimes on my
compiled with VFP 9 SP 1. I've not been able to make the time to track it
down since most clients are not running that configuration. It has something
to do with a loop process and updating records in tables. No ActiveX
controls involved, so the scenario is only similar by the SP 2. As I'm
typing, I recall it was happening on XP workstations too. I don't have any
more direction.

Since VFP 9, you can capture the coverage profile logging on with SET
COVERAGE TO... in the runtime.

Tracy Pearson
PowerChurch Software
Mike Copeland
2011-03-04 00:24:52 UTC
Permalink
Excellent! I wasn't aware that set profile would work with runtime.
Unfortunately, I'm already aware of the exact line of code that
causes the slow down, but, I guess this will confirm.



Based on your statements, I'm wondering if perhaps I installed VFP9
without the SP2 update. I'm also going to try reducing the
physical memory on the workstation from 4GB to 2GB.



I'm also thinking about trying

-- let the form instantiate without loading the SKU data

-- fire a timer event 30 seconds after the form has loaded to add
the data to the combo on the ctGrid

-- measure the time required

I suspect I'll see no change.



Currently I have a form manager object that manages all inter-form
communications, creation and destruction. I'm considering
instantiation of the form during the program start up, leaving
.visible=.f., and then just bring it forward and set .visible=.t.
when it is needed. Maybe by shifting the memory intensive activity
to a different part of the application, it will "hit" the memory
manager differently.



I've already proven that the same code, same data, same everything
on a single form, by itself, in the SLOW scenario is fast. Eurico
had suggested breaking the form out into its own EXE, but that would
eliminate too much functionality by isolating the form from
communication with all the other forms.



When straws are all you have left to grasp at...grasp away!



Mike





Mike Copeland wrote on 2011-03-03:


Tracy,















































***@leafe.com
http://leafe.com/mailman/listinfo/profox
http://leafe.com/mailman/listinfo/profoxtech
http://leafe.com/archives/search/profox
http://leafe.com/archives/byMID/profox/000e01cbd9f9$1cf9fb20$56edf160$@com


http://leafe.com/reportAbuse/000e01cbd9f9$1cf9fb20$56edf160$@com







--- StripMime Report -- processed MIME parts ---
text/html (html body -- converted)
---
Mike Copeland
2011-03-04 00:56:41 UTC
Permalink
Okay, here's the smoking gun.

Coverage info from the FAST scenario.
(EXE on server share, Windows 7 local)
This is referring to the INIT line of code that calls the AddComboItem
method.
Line 77 = FOR nnum=1 TO ALEN(tempo)
Line 78 = thisform.ctGrid.addcomboitem(1,temp.sku)
Line 79 = ENDFOR

0.000015,form_order,form_order.init,78,\\jock\c\gacs2\gacsutility.vct,5
0.000009,form_order,form_order.init,79,\\jock\c\gacs2\gacsutility.vct,5
0.000016,form_order,form_order.init,78,\\jock\c\gacs2\gacsutility.vct,5
0.000013,form_order,form_order.init,79,\\jock\c\gacs2\gacsutility.vct,5
0.000016,form_order,form_order.init,78,\\jock\c\gacs2\gacsutility.vct,5
0.000009,form_order,form_order.init,79,\\jock\c\gacs2\gacsutility.vct,5
0.000016,form_order,form_order.init,78,\\jock\c\gacs2\gacsutility.vct,5

Pretty much repeats itself (line 78, 79) 23,000 times.

Values range from a
0.000019
to
0.000015
with most being
0.000016

Now, from the coverage log on the SLOW scenario.
(Local EXE file, Windows 7)
Same code, same data

0.003365,form_order,form_order.init,78,c:\gacs\gacsutility.vct,5
0.000033,form_order,form_order.init,79,c:\gacs\gacsutility.vct,5
0.003311,form_order,form_order.init,78,c:\gacs\gacsutility.vct,5
0.000032,form_order,form_order.init,79,c:\gacs\gacsutility.vct,5
0.003456,form_order,form_order.init,78,c:\gacs\gacsutility.vct,5
0.000035,form_order,form_order.init,79,c:\gacs\gacsutility.vct,5
0.003324,form_order,form_order.init,78,c:\gacs\gacsutility.vct,5

When you go from a 0.000016 to a 0.003365 and you do it 23,000 times,
you're going to see a slow down.

So, the guilty party is the ctGrid AddComboItem method. But, I knew that.

What makes more sense than anything else is that the Visual C libraries
on the Windows 7 machine are different releases, dates, sizes, than the
Visual C libraries on the XP machine.

What doesn't make sense is why running the same code from the network
share would make it faster. I sincerely doubt that ctGrid is doing
anything different because of the location it is invoked from. Actually,
the OCX is the same in both cases...it's in a folder on the local drive
and registered with REGSVR32. I can't imagine the pain caused by trying
to register and use an OCX from a network share. Yow.

I'm going to try and summarize this info and send it to DBI in the hopes
that they'll have pity on me and in consideration for the thousands of $
I've sent them they might try recompiling the controls on a newer
platform. I'm pretty much out of other ideas.

Thanks to all for letting me tap into your brain power! If you come up
with any other ideas, please share!

The Fox is dead, long live the Fox.

Mike

PS. I'm still hoping that MSoft will need cash someday and will sell the
Fox rights and source code to someone who will resurrect it. Of course,
then it would kick VB and Access's rear...
Tracy,
Post by Tracy Pearson
Post by Mike Copeland
I may be misunderstanding your focus, but the AddComboItem loop is in
the Init of the form, before the form ever displays. Once the form
displays, there are no speed issues and the combo is never loaded
again....until a new instance of the form is called for.
The code in each of the ctGrid methods and events have to do with
recalculating tax (calling a form method) popping up a messagebox if
they enter an unknown "off the list" SKU, etc. None of them cause the
ctGrid to redraw, adjust, or be modified in any way, either on purpose
or not-on purpose.
I turned off Windows Themes in the Win7 Control Panel>Personalization,
no change.
Set sys(2700,1) in the beginning of my MAIN.PRG, and it actually
increased the times, on both the FAST and the SLOW scenarios.
Bizarre!
Mike
Mike,
No, I think you understood where I was heading. It isn't making sense. There
was an odd behavior seen once in my application that I've not been able to
take the time to track down. It is related to VFP 9 SP 2 runtimes on my
compiled with VFP 9 SP 1. I've not been able to make the time to track it
down since most clients are not running that configuration. It has something
to do with a loop process and updating records in tables. No ActiveX
controls involved, so the scenario is only similar by the SP 2. As I'm
typing, I recall it was happening on XP workstations too. I don't have any
more direction.
Since VFP 9, you can capture the coverage profile logging on with SET
COVERAGE TO... in the runtime.
Tracy Pearson
PowerChurch Software
[excessive quoting removed by server]
MB Software Solutions, LLC
2011-03-04 14:45:59 UTC
Permalink
Post by Mike Copeland
PS. I'm still hoping that MSoft will need cash someday and will sell the
Fox rights and source code to someone who will resurrect it. Of course,
then it would kick VB and Access's rear...
There won't be a VB then! Probably not Access either. But then again,
we'll all be dead before MS needs cash enough to sell this, and by that
time, will it have any value? Probably not.
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
Mike Copeland
2011-03-04 18:53:29 UTC
Permalink
Maybe, but the way Steve-o is running things, M$ofts future might not be
so guaranteed.

Mike
Post by MB Software Solutions, LLC
Post by Mike Copeland
PS. I'm still hoping that MSoft will need cash someday and will sell the
Fox rights and source code to someone who will resurrect it. Of course,
then it would kick VB and Access's rear...
There won't be a VB then! Probably not Access either. But then again,
we'll all be dead before MS needs cash enough to sell this, and by that
time, will it have any value? Probably not.
Mike Copeland
2011-03-04 03:21:34 UTC
Permalink
Just noticed that when
set coverage to logfile.log
was active, the load time was different.

On the FAST configuration, it took 6 seconds instead of 1/2.
On the SLOW config, it took only took 16 seconds instead of 78!

I can understand how all the overhead from the logging could slow the
FAST config down, but causing the SLOW configuration to speed up by a
factor of 4 is, again, bizarre. It really does, in my opinion, keep
pointing at the OCX file dragging its feet. It might just be me but it
seems that by VFP getting "in the loop" and writing to the coverage log,
it forced the OCX routine to release or timeout or something.

Interesting...and unfortunately the "black box" mentality that the OCX
option provides is now both a benefit and a hinderance. Something is
going on "in there" and I have no way of doing anything about it. (Makes
Open Source look more and more attractive...)

Mike
Post by Tracy Pearson
Post by Mike Copeland
Tracy,
I may be misunderstanding your focus, but the AddComboItem loop is in
the Init of the form, before the form ever displays. Once the form
displays, there are no speed issues and the combo is never loaded
again....until a new instance of the form is called for.
The code in each of the ctGrid methods and events have to do with
recalculating tax (calling a form method) popping up a messagebox if
they enter an unknown "off the list" SKU, etc. None of them cause the
ctGrid to redraw, adjust, or be modified in any way, either on purpose
or not-on purpose.
I turned off Windows Themes in the Win7 Control Panel>Personalization,
no change.
Set sys(2700,1) in the beginning of my MAIN.PRG, and it actually
increased the times, on both the FAST and the SLOW scenarios.
Bizarre!
Mike
Mike,
No, I think you understood where I was heading. It isn't making sense. There
was an odd behavior seen once in my application that I've not been able to
take the time to track down. It is related to VFP 9 SP 2 runtimes on my
compiled with VFP 9 SP 1. I've not been able to make the time to track it
down since most clients are not running that configuration. It has something
to do with a loop process and updating records in tables. No ActiveX
controls involved, so the scenario is only similar by the SP 2. As I'm
typing, I recall it was happening on XP workstations too. I don't have any
more direction.
Since VFP 9, you can capture the coverage profile logging on with SET
COVERAGE TO... in the runtime.
Tracy Pearson
PowerChurch Software
[excessive quoting removed by server]
k***@gmail.com
2011-03-03 15:06:39 UTC
Permalink
I don't have experience with MySQL so I probably would point to that as a likely problem. Like most developers we have
many clients converting to Win7 with no problems at all unlike the nightmare we had with Crapsta.

We have noticed one thing that may be of interest: We have a client with a new Win7 system with 12gb memory. It takes a
long time to load but the client states it is many times faster during data entry and creating reports. My explaination
(with no proof) is that our VFP9 SP2 compiled program is loading all the programs and data into memory. We do open
several data files before the first screen shows. Also, our program does not destroy screens (they are in memory and are
reused) so as you use the program it seems to get faster. Our program and all the initial data would easily fit into 1gb
memory so I can't explain why 12gb would be that much faster than a similar win7 computer with 4gb. It must be something
to do with the operating system and memory management or hardware.


----- Original Message -----
From: "Mike Copeland" <***@gmail.com>
To: <***@leafe.com>
Sent: Wednesday, March 02, 2011 12:02 PM
Subject: Windows 7 + VFP9 speed problem


It's been a while since I've been on the list, but I've run into a real
buzz-saw of a VFP problem, thanks in part to Windows 7. I'd really be
appreciative of any and all thoughts on this issue as I'm stumped.

Application: A monolithic accounting application with a few dozen forms.
Compiled exe is 6MB
Platform: Win XP or Win 7 (32 or 64 bit) plus VFP 9 SP2 and MySQL
Add to the mix: DBI Technologies ctGrid OCX file (although I don't think
this is the source of the problem)
Hardware: Not relevant, but 4GB RAM, Dual Core 3Ghz Intel CPU on Intel
G31 Mboard

Problem: When loading a form, depending on the platform, it can take
160x as long to finish.
Task: Load 23,000 SKU #s into a combo. (details below)

Times below are very very consistent, varying only about .10 second each
run.

Scenario 1: Windows XP, compiled VFP exe application, all files local
(except MySQL data)
FAST....as in 1/2 second
Scenario 2: Windows XP, run app from source code on VFP IDE, all files
local
FAST...again, around 1/2 second
Scenario 3: Windows 7 (32 or 64 bit), source code on VFP IDE, all files
local
FAST...1/2 second

...here's the problem

Scenario 4: Windows 7, compiled exe app, all files local
SLOW....80 seconds
This happens on multiple forms that have almost
identical code.

...here's the head banger
Scenario 5: Windows 7, running compiled exe from a Linux Samba share
FAST....actually a bit faster than running on
Windows XP...less than 1/2 seconds

Windows 7 is becoming unavoidable. The solution seems to be to run the
app from the server, but many details (storage of window sizes, auto
update to new version, etc.) have been designed for local workstation
storage.

What I can not understand is why Scenario 4 is so radically different.
Any suggestions?

What I've tried:
1. Turned off UAC completely. (Started with UAC on, of course.) No effect.
2. Change ownership of the folder the files are stored in. No effect.
3. Installed full VFP IDE, removed, installed VFP9 SP2 run-time only
files No effect, although I was surprised at how fast it was (Scenario 3
above)
4. Introduced delays into code loop...i.e., DOEVENTS and "wait window ''
nowait"
5. Tried saving SELECTED data in a local DBF and loading from DBF. (This
did tweak the timing a little, like 4 seconds out of 80) Even tried
saving static data in DBF and not even involving the MySQL process.
6. Created single form with nothing but the DBI grid OCX object and
compiled as a 48Kb application. This ran fast, 1/2 second to load, but
while informative it is hardly useful.
7. I've tested and tried placing the TMPFILES location local and remote,
and let Windows manage it vs. "manual override." No change.

All in all, it seems to be pointing at a problem with the interaction
between Windows 7 and VFP9 SP2 and memory management.

I'm sure I've missed something, and I know this is a lot to read, but I
would very much appreciate any suggestions. I know of no better place to
go than here where the best and the brightest connect.

Oh, here's the code from the INIT event on the form (I've tried various
other events, and even put it in the click event of a button on the
form, no change)
Also, you'll notice there's no indication of how I'm getting the data
from MySQL. The sample below has the same speed issues described above,
but as you can see the retrieval from the MySQL server is not involved
in the timing and is actually very fast in all scenarios.
----------------------------------------------------------

MESSAGEBOX('Starting to load Grid. Click OK to start...',0+64,'Notice')
LOCAL ttimestart,ttimeexp
SELECT sku FROM skus into temp WHERE active=1 order by sku
SELECT temp
GO TOP IN temp

ttimestart=seconds()

SCAN WHILE !EOF('temp')
thisform.ctGrid.addcomboitem(1,temp.sku)
ENDSCAN

ttimeexp=seconds()-ttimestart

MESSAGEBOX('Finished.'+CHR(13)+ALLTRIM(STR(RECCOUNT('temp')))+' items added.'+;
CHR(13)+'Time elapsed: '+ALLTRIM(STR(ttimeexp,6,2))+' seconds',0+64,'Notice')
-------------------------------------------------------------------------

Thanks again!
Mike Copeland




[excessive quoting removed by server]
Tracy Pearson
2011-03-03 15:55:55 UTC
Permalink
Post by k***@gmail.com
I don't have experience with MySQL so I probably would point to that
as a likely problem. Like most developers we have many clients
converting to Win7 with no problems at all unlike the nightmare we had
with Crapsta.
We have noticed one thing that may be of interest: We have a client
with a new Win7 system with 12gb memory. It takes a long time to load
but the client states it is many times faster during data entry and
creating reports. My explaination (with no proof) is that our VFP9 SP2
compiled program is loading all the programs and data into memory. We
do open several data files before the first screen shows. Also, our
program does not destroy screens (they are in memory and are
reused) so as you use the program it seems to get faster. Our program
and all the initial data would easily fit into 1gb memory so I can't
explain why 12gb would be that much faster than a similar win7
computer with 4gb. It must be something to do with the operating
system and memory management or hardware.
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work in
VFP 9 at all

Tracy Pearson
PowerChurch Software
MB Software Solutions, LLC
2011-03-03 17:32:35 UTC
Permalink
Post by Tracy Pearson
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work in
VFP 9 at all
Use Ed Leafe's Setmemory.prg. It's in the Downloads section on ProFox.
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
Mike Copeland
2011-03-03 21:42:10 UTC
Permalink
Done. Thanks Mike!

As I said in another response, I have used this in all my Windows VFP
apps for many years...it was already in the application I'm having speed
issues with...I re-enabled it and unfortunately it didn't help.

****************************************
func SetMem
* Requests free RAM memory value from Windows, sets VFP to only utilize
that amount.
* Prevents slow performance for users who run many apps at the same time.
* Keep with CHARTOBIN function below!!
LOCAL lnAvailableMem, lpMemoryStatus, lnPct
DECLARE GlobalMemoryStatus IN Win32API STRING @lpMemoryStatus
lpMemoryStatus = REPLICATE(CHR(0), 32)
GlobalMemoryStatus(@lpMemoryStatus)
lnAvailableMem = CharToBin(SUBSTR(lpMemoryStatus, 13, 4))
* Fine tuning option. Specify a decimal value to allocate less than
100%
* i.e. .5 would be 50%
*!* lnPct = 1
*!* IF TYPE("main.nSetMemoryPct") == "N"
*!* lnPct = goApp.nSetMemoryPct
*!* ENDIF
*!* lnAvailableMem = (lnAvailableMem * lnPct)
SYS(3050, 1, lnAvailableMem)
SYS(3050, 2, (lnAvailableMem/2) )
RETURN lnAvailableMem
*********************************************
func CharToBin
param tcWord
* only called by SETMEM()
LOCAL lnChar, lnWord
lnWord = 0
FOR lnChar = 1 TO LEN(tcWord)
lnWord = lnWord + (ASC(SUBSTR(tcWord, lnChar, 1)) * (2 ^ (8 *
(lnChar - 1))))
ENDFOR
RETURN lnWord
*********************************************

I'm pretty sure that's the one.

Mike
Post by MB Software Solutions, LLC
Post by Tracy Pearson
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work in
VFP 9 at all
Use Ed Leafe's Setmemory.prg. It's in the Downloads section on ProFox.
Sytze de Boer
2011-03-03 21:45:48 UTC
Permalink
What other files are necessary to run VFP9.exe, in order to run vfp9.exe
Myapp
Post by Mike Copeland
Done. Thanks Mike!
As I said in another response, I have used this in all my Windows VFP
apps for many years...it was already in the application I'm having speed
issues with...I re-enabled it and unfortunately it didn't help.
****************************************
func SetMem
* Requests free RAM memory value from Windows, sets VFP to only utilize
that amount.
* Prevents slow performance for users who run many apps at the same time.
* Keep with CHARTOBIN function below!!
LOCAL lnAvailableMem, lpMemoryStatus, lnPct
lpMemoryStatus = REPLICATE(CHR(0), 32)
lnAvailableMem = CharToBin(SUBSTR(lpMemoryStatus, 13, 4))
* Fine tuning option. Specify a decimal value to allocate less than
100%
* i.e. .5 would be 50%
*!* lnPct = 1
*!* IF TYPE("main.nSetMemoryPct") == "N"
*!* lnPct = goApp.nSetMemoryPct
*!* ENDIF
*!* lnAvailableMem = (lnAvailableMem * lnPct)
SYS(3050, 1, lnAvailableMem)
SYS(3050, 2, (lnAvailableMem/2) )
RETURN lnAvailableMem
*********************************************
func CharToBin
param tcWord
* only called by SETMEM()
LOCAL lnChar, lnWord
lnWord = 0
FOR lnChar = 1 TO LEN(tcWord)
lnWord = lnWord + (ASC(SUBSTR(tcWord, lnChar, 1)) * (2 ^ (8 *
(lnChar - 1))))
ENDFOR
RETURN lnWord
*********************************************
I'm pretty sure that's the one.
Mike
Post by MB Software Solutions, LLC
Post by Tracy Pearson
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work
in
Post by MB Software Solutions, LLC
Post by Tracy Pearson
VFP 9 at all
Use Ed Leafe's Setmemory.prg. It's in the Downloads section on ProFox.
[excessive quoting removed by server]
k***@gmail.com
2011-03-03 22:23:07 UTC
Permalink
Has anyone mentioned defragging the hard drive? I have seen that make a big difference. (maybe not 80 times though)


----- Original Message -----
From: "Sytze de Boer" <***@gmail.com>
To: "profox" <***@leafe.com>
Sent: Thursday, March 03, 2011 1:45 PM
Subject: Re: Windows 7 + VFP9 speed problem


What other files are necessary to run VFP9.exe, in order to run vfp9.exe
Myapp
Post by Mike Copeland
Done. Thanks Mike!
As I said in another response, I have used this in all my Windows VFP
apps for many years...it was already in the application I'm having speed
issues with...I re-enabled it and unfortunately it didn't help.
****************************************
func SetMem
* Requests free RAM memory value from Windows, sets VFP to only utilize
that amount.
* Prevents slow performance for users who run many apps at the same time.
* Keep with CHARTOBIN function below!!
LOCAL lnAvailableMem, lpMemoryStatus, lnPct
lpMemoryStatus = REPLICATE(CHR(0), 32)
lnAvailableMem = CharToBin(SUBSTR(lpMemoryStatus, 13, 4))
* Fine tuning option. Specify a decimal value to allocate less than
100%
* i.e. .5 would be 50%
*!* lnPct = 1
*!* IF TYPE("main.nSetMemoryPct") == "N"
*!* lnPct = goApp.nSetMemoryPct
*!* ENDIF
*!* lnAvailableMem = (lnAvailableMem * lnPct)
SYS(3050, 1, lnAvailableMem)
SYS(3050, 2, (lnAvailableMem/2) )
RETURN lnAvailableMem
*********************************************
func CharToBin
param tcWord
* only called by SETMEM()
LOCAL lnChar, lnWord
lnWord = 0
FOR lnChar = 1 TO LEN(tcWord)
lnWord = lnWord + (ASC(SUBSTR(tcWord, lnChar, 1)) * (2 ^ (8 *
(lnChar - 1))))
ENDFOR
RETURN lnWord
*********************************************
I'm pretty sure that's the one.
Mike
Post by MB Software Solutions, LLC
Post by Tracy Pearson
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work
in
Post by MB Software Solutions, LLC
Post by Tracy Pearson
VFP 9 at all
Use Ed Leafe's Setmemory.prg. It's in the Downloads section on ProFox.
[excessive quoting removed by server]
Mike Copeland
2011-03-03 23:25:18 UTC
Permalink
Okay, now we're grasping...but I'll try it!

Remember though, that this is a brand new system. It has has the
following installed:
Windows 7
Avast Antivirus
Adobe Acrobat
and my application along with VFP9 runtime files.
I haven't even gotten as far as installing printer drivers.

Unfortunately, just tried it and the defrag didn't help any. But thanks!

Mike
Post by k***@gmail.com
Has anyone mentioned defragging the hard drive? I have seen that make a big difference. (maybe not 80 times though)
----- Original Message -----
Sent: Thursday, March 03, 2011 1:45 PM
Subject: Re: Windows 7 + VFP9 speed problem
What other files are necessary to run VFP9.exe, in order to run vfp9.exe
Myapp
Post by Mike Copeland
Done. Thanks Mike!
As I said in another response, I have used this in all my Windows VFP
apps for many years...it was already in the application I'm having speed
issues with...I re-enabled it and unfortunately it didn't help.
****************************************
func SetMem
* Requests free RAM memory value from Windows, sets VFP to only utilize
that amount.
* Prevents slow performance for users who run many apps at the same time.
* Keep with CHARTOBIN function below!!
LOCAL lnAvailableMem, lpMemoryStatus, lnPct
lpMemoryStatus = REPLICATE(CHR(0), 32)
lnAvailableMem = CharToBin(SUBSTR(lpMemoryStatus, 13, 4))
* Fine tuning option. Specify a decimal value to allocate less than
100%
* i.e. .5 would be 50%
*!* lnPct = 1
*!* IF TYPE("main.nSetMemoryPct") == "N"
*!* lnPct = goApp.nSetMemoryPct
*!* ENDIF
*!* lnAvailableMem = (lnAvailableMem * lnPct)
SYS(3050, 1, lnAvailableMem)
SYS(3050, 2, (lnAvailableMem/2) )
RETURN lnAvailableMem
*********************************************
func CharToBin
param tcWord
* only called by SETMEM()
LOCAL lnChar, lnWord
lnWord = 0
FOR lnChar = 1 TO LEN(tcWord)
lnWord = lnWord + (ASC(SUBSTR(tcWord, lnChar, 1)) * (2 ^ (8 *
(lnChar - 1))))
ENDFOR
RETURN lnWord
*********************************************
I'm pretty sure that's the one.
Mike
Post by MB Software Solutions, LLC
Post by Tracy Pearson
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work
in
Post by MB Software Solutions, LLC
Post by Tracy Pearson
VFP 9 at all
Use Ed Leafe's Setmemory.prg. It's in the Downloads section on ProFox.
[excessive quoting removed by server]
Dan Covill
2011-03-04 01:21:22 UTC
Permalink
Post by Mike Copeland
Okay, now we're grasping...but I'll try it!
Have you tried painting your face blue and running the app while
standing in a pail of molasses? You've tried damned near everything else!

The most interesting thing about this problem is that the performance is
bad when running the .exe, but good if you run the .prgs (i.e., really
the .frxs). My intuition is still that it has something to do with that
23,000 iteration loop. The huge loop makes it highly probable that it
has to do with the way memory is managed, and that means that the .exe
manages memory differently from the .frx. But wait! You've got an .ocx
doing all the work in the loop. So what about the .ocx could act
different in an exe?

I never use .ocxs, but I'm under the impression that they are already
compiled, and thus aren't included in 'build'ing your project. If this
is so, then Tracy's point about the run-times becomes interesting. IOW,
are you compiling your .exe with the same version (SP1 vs SP2) that the
OCX was compiled with, and do the run-times match the version you and/or
the OCX are compiled with? Note that there were at least two versions
of SP2, plus two hot fixes to be applied afterward.

I've seen something like this (but not nearly as dramatic) in a program
that was in a loop appending to a long string. Turns out that VFP
appends by allocating a new mem area, copying the existing string, then
appending the added chars. I still suspect the addtolist() method,
whatever it's called, is where the time is going.

Short run, running from a server gets you off the hook. Long run, I
think we need to find a better way to populate that list. Maybe from an
array?

Dan Covill
Mike Copeland
2011-03-04 03:03:19 UTC
Permalink
Hmmm, well Dan, I haven't tried the blue face paint, but I have tried
holding my breath and I did almost turn blue.

I agree that 23,000 items in a lookup list is excessive and I agree it's
not good practice. But, up until this Windows 7 thing, it has worked
beautifully! Very fast and very useful.

The big benefit to the current design is that the SKUs that they are
entering can be up to 18 characters long, have NO rhyme or reason, and
change every couple of weeks...new ones added, old ones gathering dust
(they don't want to remove the old ones just in case they want to look
something up.) They have been adding 200 to 300 new SKUs every other
week on average. Here's a list of some of them:
DCSRGSC305SSLP
DCSRGS486GLSSLP
HL67A750A1FXZA
UR48DTCLRGLSRFD
UR48HT4CLRGLSDR
VGRC4854GQDCOLO
XXUN55B6000VFXZA
Now, all of the characters in the alpha/numeric string means something,
but it's not consistent (what it means.) The "48" might be the width,
or it might have no bearing on any specification of the appliance (my
app is primarily used by white-good retail stores.)

Where the problems really come in is that the companies that use my
software have a high turnover in sales people, and the newbies are
clueless on SKU #s and what they might mean. And, unfortunately, if they
get one letter or digit wrong, it can produce a costly problem due to
the wrong item being ordered and/or delivered...sometimes the mistake is
caught, sometimes not.

The biggest problem, though, is that the sales manager (new co-owner)
has the mentality of "I don't care what you do, just do it as fast as
you can! We have more tickets to write!" so there are a lot of mistakes
and errors with little to no emphasis on catching mistakes. I've tried
to get them to switch over to barcode labels and scanners for SKU input,
but they can't keep their price tags straight, much less bar code labels.

Anyway, enough with the defense of how it's done.

OCX files are typically written in Visual C+...at least that's my
understanding. They are, essentially, much like DLLs, or FLLs. Beyond
that is beyond my understanding. To use them, you copy the OCX file onto
the hard drive, register it with "regsvr32 nameof.ocx" and it becomes
available for use in your application.

As you said, the most confusing part of this is that there is such
performance difference between the run-time execution and running the
PRG files from the IDE, with everything else the same. And, likewise,
the difference in performance between the run-time execution with the
EXE file being on a networked drive vs. the same code being loaded
locally. THAT really makes no sense. That's what stumped me. Quite
obviously there is a significant difference in how VFP allocates and
manages memory when the pseudo code is loaded from a network share vs. a
local folder.

Oh, and to your last comment, I am loading the list from an array now. I
tried using a cursor and switched to the array approach during the
testing (after the problem showed up.) Using an array is about 40%
faster...unless it's run from an EXE on the local Win7 drive! Then it's
about 2 seconds faster (76 instead of 78 seconds).

But, again, thank you for the analysis!

Mike
Post by Dan Covill
Post by Mike Copeland
Okay, now we're grasping...but I'll try it!
Have you tried painting your face blue and running the app while
standing in a pail of molasses? You've tried damned near everything else!
The most interesting thing about this problem is that the performance is
bad when running the .exe, but good if you run the .prgs (i.e., really
the .frxs). My intuition is still that it has something to do with that
23,000 iteration loop. The huge loop makes it highly probable that it
has to do with the way memory is managed, and that means that the .exe
manages memory differently from the .frx. But wait! You've got an .ocx
doing all the work in the loop. So what about the .ocx could act
different in an exe?
I never use .ocxs, but I'm under the impression that they are already
compiled, and thus aren't included in 'build'ing your project. If this
is so, then Tracy's point about the run-times becomes interesting. IOW,
are you compiling your .exe with the same version (SP1 vs SP2) that the
OCX was compiled with, and do the run-times match the version you and/or
the OCX are compiled with? Note that there were at least two versions
of SP2, plus two hot fixes to be applied afterward.
I've seen something like this (but not nearly as dramatic) in a program
that was in a loop appending to a long string. Turns out that VFP
appends by allocating a new mem area, copying the existing string, then
appending the added chars. I still suspect the addtolist() method,
whatever it's called, is where the time is going.
Short run, running from a server gets you off the hook. Long run, I
think we need to find a better way to populate that list. Maybe from an
array?
Dan Covill
[excessive quoting removed by server]
Fred Taylor
2011-03-04 06:36:22 UTC
Permalink
What's your _VFP.AutoYield setting? It should probably be .F., at least for
the code around the OCX adding data code. Maybe those settings are
different between the IDE and the runtime?

Fred
Post by Mike Copeland
Hmmm, well Dan, I haven't tried the blue face paint, but I have tried
holding my breath and I did almost turn blue.
I agree that 23,000 items in a lookup list is excessive and I agree it's
not good practice. But, up until this Windows 7 thing, it has worked
beautifully! Very fast and very useful.
The big benefit to the current design is that the SKUs that they are
entering can be up to 18 characters long, have NO rhyme or reason, and
change every couple of weeks...new ones added, old ones gathering dust
(they don't want to remove the old ones just in case they want to look
something up.) They have been adding 200 to 300 new SKUs every other
DCSRGSC305SSLP
DCSRGS486GLSSLP
HL67A750A1FXZA
UR48DTCLRGLSRFD
UR48HT4CLRGLSDR
VGRC4854GQDCOLO
XXUN55B6000VFXZA
Now, all of the characters in the alpha/numeric string means something,
but it's not consistent (what it means.) The "48" might be the width,
or it might have no bearing on any specification of the appliance (my
app is primarily used by white-good retail stores.)
Where the problems really come in is that the companies that use my
software have a high turnover in sales people, and the newbies are
clueless on SKU #s and what they might mean. And, unfortunately, if they
get one letter or digit wrong, it can produce a costly problem due to
the wrong item being ordered and/or delivered...sometimes the mistake is
caught, sometimes not.
The biggest problem, though, is that the sales manager (new co-owner)
has the mentality of "I don't care what you do, just do it as fast as
you can! We have more tickets to write!" so there are a lot of mistakes
and errors with little to no emphasis on catching mistakes. I've tried
to get them to switch over to barcode labels and scanners for SKU input,
but they can't keep their price tags straight, much less bar code labels.
Anyway, enough with the defense of how it's done.
OCX files are typically written in Visual C+...at least that's my
understanding. They are, essentially, much like DLLs, or FLLs. Beyond
that is beyond my understanding. To use them, you copy the OCX file onto
the hard drive, register it with "regsvr32 nameof.ocx" and it becomes
available for use in your application.
As you said, the most confusing part of this is that there is such
performance difference between the run-time execution and running the
PRG files from the IDE, with everything else the same. And, likewise,
the difference in performance between the run-time execution with the
EXE file being on a networked drive vs. the same code being loaded
locally. THAT really makes no sense. That's what stumped me. Quite
obviously there is a significant difference in how VFP allocates and
manages memory when the pseudo code is loaded from a network share vs. a
local folder.
Oh, and to your last comment, I am loading the list from an array now. I
tried using a cursor and switched to the array approach during the
testing (after the problem showed up.) Using an array is about 40%
faster...unless it's run from an EXE on the local Win7 drive! Then it's
about 2 seconds faster (76 instead of 78 seconds).
But, again, thank you for the analysis!
Mike
Post by Dan Covill
Post by Mike Copeland
Okay, now we're grasping...but I'll try it!
Have you tried painting your face blue and running the app while
standing in a pail of molasses? You've tried damned near everything
else!
Post by Dan Covill
The most interesting thing about this problem is that the performance is
bad when running the .exe, but good if you run the .prgs (i.e., really
the .frxs). My intuition is still that it has something to do with that
23,000 iteration loop. The huge loop makes it highly probable that it
has to do with the way memory is managed, and that means that the .exe
manages memory differently from the .frx. But wait! You've got an .ocx
doing all the work in the loop. So what about the .ocx could act
different in an exe?
I never use .ocxs, but I'm under the impression that they are already
compiled, and thus aren't included in 'build'ing your project. If this
is so, then Tracy's point about the run-times becomes interesting. IOW,
are you compiling your .exe with the same version (SP1 vs SP2) that the
OCX was compiled with, and do the run-times match the version you and/or
the OCX are compiled with? Note that there were at least two versions
of SP2, plus two hot fixes to be applied afterward.
I've seen something like this (but not nearly as dramatic) in a program
that was in a loop appending to a long string. Turns out that VFP
appends by allocating a new mem area, copying the existing string, then
appending the added chars. I still suspect the addtolist() method,
whatever it's called, is where the time is going.
Short run, running from a server gets you off the hook. Long run, I
think we need to find a better way to populate that list. Maybe from an
array?
Dan Covill
[excessive quoting removed by server]
Mike Copeland
2011-03-04 06:46:37 UTC
Permalink
Thanks Fred!

Yes, _vfp.autoyield is set to .F. in the form's Load event. I'm not
aware of any place to set this other than in the code that is executed
both during runtime and IDE.

Along those same lines, and remembering something about "very tight
loops" causing problems before with VFP, I added a DOEVENT (and, as an
alternate, a wait window nowait "") in the loop with the AddComboItem
method call. It did slow it down even more, and the slow down was
consistent in both the fast and slow environments, but it didn't help.

So far, adding "Set logging to file.log" before and after the method
call has had the biggest improvement! I guess I could do that and then
delete the file immediately after.

And, let me take this time to thank everyone else who took part of their
day to read and think about this issue that I'm having. I do appreciate
it. I hope I'll be able to return the favor some day.

Mike
Post by Fred Taylor
What's your _VFP.AutoYield setting? It should probably be .F., at least for
the code around the OCX adding data code. Maybe those settings are
different between the IDE and the runtime?
Fred
Post by Mike Copeland
Hmmm, well Dan, I haven't tried the blue face paint, but I have tried
holding my breath and I did almost turn blue.
I agree that 23,000 items in a lookup list is excessive and I agree it's
not good practice. But, up until this Windows 7 thing, it has worked
beautifully! Very fast and very useful.
The big benefit to the current design is that the SKUs that they are
entering can be up to 18 characters long, have NO rhyme or reason, and
change every couple of weeks...new ones added, old ones gathering dust
(they don't want to remove the old ones just in case they want to look
something up.) They have been adding 200 to 300 new SKUs every other
DCSRGSC305SSLP
DCSRGS486GLSSLP
HL67A750A1FXZA
UR48DTCLRGLSRFD
UR48HT4CLRGLSDR
VGRC4854GQDCOLO
XXUN55B6000VFXZA
Now, all of the characters in the alpha/numeric string means something,
but it's not consistent (what it means.) The "48" might be the width,
or it might have no bearing on any specification of the appliance (my
app is primarily used by white-good retail stores.)
Where the problems really come in is that the companies that use my
software have a high turnover in sales people, and the newbies are
clueless on SKU #s and what they might mean. And, unfortunately, if they
get one letter or digit wrong, it can produce a costly problem due to
the wrong item being ordered and/or delivered...sometimes the mistake is
caught, sometimes not.
The biggest problem, though, is that the sales manager (new co-owner)
has the mentality of "I don't care what you do, just do it as fast as
you can! We have more tickets to write!" so there are a lot of mistakes
and errors with little to no emphasis on catching mistakes. I've tried
to get them to switch over to barcode labels and scanners for SKU input,
but they can't keep their price tags straight, much less bar code labels.
Anyway, enough with the defense of how it's done.
OCX files are typically written in Visual C+...at least that's my
understanding. They are, essentially, much like DLLs, or FLLs. Beyond
that is beyond my understanding. To use them, you copy the OCX file onto
the hard drive, register it with "regsvr32 nameof.ocx" and it becomes
available for use in your application.
As you said, the most confusing part of this is that there is such
performance difference between the run-time execution and running the
PRG files from the IDE, with everything else the same. And, likewise,
the difference in performance between the run-time execution with the
EXE file being on a networked drive vs. the same code being loaded
locally. THAT really makes no sense. That's what stumped me. Quite
obviously there is a significant difference in how VFP allocates and
manages memory when the pseudo code is loaded from a network share vs. a
local folder.
Oh, and to your last comment, I am loading the list from an array now. I
tried using a cursor and switched to the array approach during the
testing (after the problem showed up.) Using an array is about 40%
faster...unless it's run from an EXE on the local Win7 drive! Then it's
about 2 seconds faster (76 instead of 78 seconds).
But, again, thank you for the analysis!
Mike
Post by Dan Covill
Post by Mike Copeland
Okay, now we're grasping...but I'll try it!
Have you tried painting your face blue and running the app while
standing in a pail of molasses? You've tried damned near everything
else!
Post by Dan Covill
The most interesting thing about this problem is that the performance is
bad when running the .exe, but good if you run the .prgs (i.e., really
the .frxs). My intuition is still that it has something to do with that
23,000 iteration loop. The huge loop makes it highly probable that it
has to do with the way memory is managed, and that means that the .exe
manages memory differently from the .frx. But wait! You've got an .ocx
doing all the work in the loop. So what about the .ocx could act
different in an exe?
I never use .ocxs, but I'm under the impression that they are already
compiled, and thus aren't included in 'build'ing your project. If this
is so, then Tracy's point about the run-times becomes interesting. IOW,
are you compiling your .exe with the same version (SP1 vs SP2) that the
OCX was compiled with, and do the run-times match the version you and/or
the OCX are compiled with? Note that there were at least two versions
of SP2, plus two hot fixes to be applied afterward.
I've seen something like this (but not nearly as dramatic) in a program
that was in a loop appending to a long string. Turns out that VFP
appends by allocating a new mem area, copying the existing string, then
appending the added chars. I still suspect the addtolist() method,
whatever it's called, is where the time is going.
Short run, running from a server gets you off the hook. Long run, I
think we need to find a better way to populate that list. Maybe from an
array?
Dan Covill
[excessive quoting removed by server]
Richard Kaye
2011-03-04 14:42:38 UTC
Permalink
Did you try using the FORCE keyword on the DOEVENTS call?
I don't recall if you mentioned your actual SYS(3050) setup. What values did you use?

--
rk

-----Original Message-----
From: profoxtech-***@leafe.com [mailto:profoxtech-***@leafe.com] On Behalf Of Mike Copeland
Sent: Friday, March 04, 2011 1:47 AM
To: ***@leafe.com
Subject: Re: Windows 7 + VFP9 speed problem

Thanks Fred!

Yes, _vfp.autoyield is set to .F. in the form's Load event. I'm not aware of any place to set this other than in the code that is executed both during runtime and IDE.

Along those same lines, and remembering something about "very tight loops" causing problems before with VFP, I added a DOEVENT (and, as an alternate, a wait window nowait "") in the loop with the AddComboItem method call. It did slow it down even more, and the slow down was consistent in both the fast and slow environments, but it didn't help.

So far, adding "Set logging to file.log" before and after the method call has had the biggest improvement! I guess I could do that and then delete the file immediately after.
Mike Copeland
2011-03-04 03:42:24 UTC
Permalink
The three VFP files that are needed, to my knowledge, are
GDIPLUS.DLL
VFP9R.DLL
VFP9RENU.DLL
Not sure about the GDIPLUS.DLL, but I'm using XFRX to write PDF files
for reports, and I think it likes having GDIPLUS.DLL around.

I did notice that the runtime files I've been distributing with my apps
are dated 12/2004. I'm wondering if maybe these are pre SP2 (assuming
there was an update to the VFP9R and VFP9RENU files with the SP2.) The
file version shows 9.0.0.2412 while the ones on my system show
9.0.0.5815. Hmmm, update is in order.

Installed new runtime files, rebooted, getting the same performance.
DANG! Wow, I was hopeful there for a minute...

By the way, I did try two different releases of ctGRID....version 3.0
and v4.01. Same performance.

Mike
Post by Sytze de Boer
What other files are necessary to run VFP9.exe, in order to run vfp9.exe
Myapp
Post by Mike Copeland
Done. Thanks Mike!
As I said in another response, I have used this in all my Windows VFP
apps for many years...it was already in the application I'm having speed
issues with...I re-enabled it and unfortunately it didn't help.
****************************************
func SetMem
* Requests free RAM memory value from Windows, sets VFP to only utilize
that amount.
* Prevents slow performance for users who run many apps at the same time.
* Keep with CHARTOBIN function below!!
LOCAL lnAvailableMem, lpMemoryStatus, lnPct
lpMemoryStatus = REPLICATE(CHR(0), 32)
lnAvailableMem = CharToBin(SUBSTR(lpMemoryStatus, 13, 4))
* Fine tuning option. Specify a decimal value to allocate less than
100%
* i.e. .5 would be 50%
*!* lnPct = 1
*!* IF TYPE("main.nSetMemoryPct") == "N"
*!* lnPct = goApp.nSetMemoryPct
*!* ENDIF
*!* lnAvailableMem = (lnAvailableMem * lnPct)
SYS(3050, 1, lnAvailableMem)
SYS(3050, 2, (lnAvailableMem/2) )
RETURN lnAvailableMem
*********************************************
func CharToBin
param tcWord
* only called by SETMEM()
LOCAL lnChar, lnWord
lnWord = 0
FOR lnChar = 1 TO LEN(tcWord)
lnWord = lnWord + (ASC(SUBSTR(tcWord, lnChar, 1)) * (2 ^ (8 *
(lnChar - 1))))
ENDFOR
RETURN lnWord
*********************************************
I'm pretty sure that's the one.
Mike
Post by MB Software Solutions, LLC
Post by Tracy Pearson
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work
in
Post by MB Software Solutions, LLC
Post by Tracy Pearson
VFP 9 at all
Use Ed Leafe's Setmemory.prg. It's in the Downloads section on ProFox.
[excessive quoting removed by server]
MB Software Solutions, LLC
2011-03-04 14:48:20 UTC
Permalink
Post by Mike Copeland
The three VFP files that are needed, to my knowledge, are
GDIPLUS.DLL
VFP9R.DLL
VFP9RENU.DLL
Not sure about the GDIPLUS.DLL, but I'm using XFRX to write PDF files
for reports, and I think it likes having GDIPLUS.DLL around.
I did notice that the runtime files I've been distributing with my apps
are dated 12/2004. I'm wondering if maybe these are pre SP2 (assuming
there was an update to the VFP9R and VFP9RENU files with the SP2.) The
file version shows 9.0.0.2412 while the ones on my system show
9.0.0.5815. Hmmm, update is in order.
Installed new runtime files, rebooted, getting the same performance.
DANG! Wow, I was hopeful there for a minute...
By the way, I did try two different releases of ctGRID....version 3.0
and v4.01. Same performance.
Are you putting these runtime files in the application's folder
directly, or elsewhere? Not sure that that would make a difference
though, in your case.
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
Eurico Chagas Filho
2011-03-04 17:02:33 UTC
Permalink
Mike

Have u tried to delay the loading of the grid ? Something like a button that the
user
has to press in order to fill the grid.

E.
Mike Copeland
2011-03-04 18:49:27 UTC
Permalink
Eurico,

Yes. I tried both with a button and a timer. Both acted the same
way...slow in the slow scenario, fast in the fast scenario.

Mike
Post by Eurico Chagas Filho
Mike
Have u tried to delay the loading of the grid ? Something like a button that the
user
has to press in order to fill the grid.
E.
[excessive quoting removed by server]
Mike Copeland
2011-03-05 23:18:14 UTC
Permalink
PROBLEM SOLVED

I used Windows Anytime Upgrade to upgrade the Win7 Home Premium 32-bit
system to Win7 PRO 32-bit, un-registered the OCX control, re-registered
it, ran my EXE locally, and loaded all 23,000 SKUs in under 1/2 second.

I think it's pretty obvious:
There is a system function call being used by the DBI ctGrid (both
version 3 and 4) OCX file when it is accepting data input for the grid
combo that Win7 Home Premium does not support well. As the ctGrid is a
"black box" (and because I'm not smart enough) I have no way to do
anything about the problem other than complain to DBI and upgrade all
Win7 HOME systems to Win7 PRO at $77 each. I guess it's good to find the
problem and I don't have to reinstall anything!

Many thanks, again, to all of you who contributed your time and
experience in an effort to help. While none of the suggestions may have
nailed the real problem, they all provided priceless confirmation and
trouble-shooting validation!

Mike
Post by MB Software Solutions, LLC
Post by Mike Copeland
The three VFP files that are needed, to my knowledge, are
GDIPLUS.DLL
VFP9R.DLL
VFP9RENU.DLL
Not sure about the GDIPLUS.DLL, but I'm using XFRX to write PDF files
for reports, and I think it likes having GDIPLUS.DLL around.
I did notice that the runtime files I've been distributing with my apps
are dated 12/2004. I'm wondering if maybe these are pre SP2 (assuming
there was an update to the VFP9R and VFP9RENU files with the SP2.) The
file version shows 9.0.0.2412 while the ones on my system show
9.0.0.5815. Hmmm, update is in order.
Installed new runtime files, rebooted, getting the same performance.
DANG! Wow, I was hopeful there for a minute...
By the way, I did try two different releases of ctGRID....version 3.0
and v4.01. Same performance.
Are you putting these runtime files in the application's folder
directly, or elsewhere? Not sure that that would make a difference
though, in your case.
MB Software Solutions, LLC
2011-03-05 23:52:53 UTC
Permalink
Post by Mike Copeland
PROBLEM SOLVED
I used Windows Anytime Upgrade to upgrade the Win7 Home Premium 32-bit
system to Win7 PRO 32-bit, un-registered the OCX control, re-registered
it, ran my EXE locally, and loaded all 23,000 SKUs in under 1/2 second.
There is a system function call being used by the DBI ctGrid (both
version 3 and 4) OCX file when it is accepting data input for the grid
combo that Win7 Home Premium does not support well. As the ctGrid is a
"black box" (and because I'm not smart enough) I have no way to do
anything about the problem other than complain to DBI and upgrade all
Win7 HOME systems to Win7 PRO at $77 each. I guess it's good to find the
problem and I don't have to reinstall anything!
Many thanks, again, to all of you who contributed your time and
experience in an effort to help. While none of the suggestions may have
nailed the real problem, they all provided priceless confirmation and
trouble-shooting validation!
Glad you got it!
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
Alan Bourke
2011-03-06 12:16:35 UTC
Permalink
Post by Mike Copeland
PROBLEM SOLVED
There is a system function call being used by the DBI ctGrid (both
version 3 and 4) OCX file when it is accepting data input for the grid
combo that Win7 Home Premium does not support well.
I would have thought Home and Pro are code-identical apart from how they
are activated.
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
Mike Copeland
2011-03-06 18:43:08 UTC
Permalink
I figured the same...I thought that the code for "everything 7" had
already been installed with the Home package and given a Home, or Pro,
or Ultimate authorization code, Win7 would act accordingly...turning on
and off features. Not so.

After putting in the $77 code, it took about 10 to 15 minutes to
download and install quite a bit of stuff. (No idea what or how much as
the screen was pretty non-informative as the process progressed.) The
process also rebooted twice...good old Windows...just to let me know it
was authentic.

I did find, also, that sys(3050,1) throws an error on the 64-bit Win7
Pro, but not the 32-bit Home or Pro. That was in the SETMEM.PRG routine
that I got from Ed's board years ago. I could be wrong because I didn't
spend a lot of time testing, but it didn't appear that sys(3050) did
anything at all in any of the versions of Win7.

Mike
Post by Alan Bourke
Post by Mike Copeland
PROBLEM SOLVED
There is a system function call being used by the DBI ctGrid (both
version 3 and 4) OCX file when it is accepting data input for the grid
combo that Win7 Home Premium does not support well.
I would have thought Home and Pro are code-identical apart from how they
are activated.
MB Software Solutions, LLC
2011-03-07 04:44:03 UTC
Permalink
Post by Mike Copeland
I figured the same...I thought that the code for "everything 7" had
already been installed with the Home package and given a Home, or Pro,
or Ultimate authorization code, Win7 would act accordingly...turning on
and off features. Not so.
After putting in the $77 code, it took about 10 to 15 minutes to
download and install quite a bit of stuff. (No idea what or how much as
the screen was pretty non-informative as the process progressed.) The
process also rebooted twice...good old Windows...just to let me know it
was authentic.
I did find, also, that sys(3050,1) throws an error on the 64-bit Win7
Pro, but not the 32-bit Home or Pro. That was in the SETMEM.PRG routine
that I got from Ed's board years ago. I could be wrong because I didn't
spend a lot of time testing, but it didn't appear that sys(3050) did
anything at all in any of the versions of Win7.
That's why I told you that you'd have to adjust it to set the max memory
at 2 GB (?) since Vista and beyond can go higher. I think I set mine to
just ignore SetMemory's code if the OS() was higher than XP's value.
Not the best fix, but quick fix for now. OR, I used values like 1600000
and 800000 for foreground/background respectively (by force instead of
letting calculations be used).
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
Mike Copeland
2011-03-07 04:49:03 UTC
Permalink
Ahhh....so you did!

I tried setting the values (the third parameter) to different values and
nothing seemed to act different, and none of the sys() values that I
checked changed. I'm not saying it's not useful but I've not used it for
quite a while, so until it's broke...

Mike
Post by MB Software Solutions, LLC
Post by Mike Copeland
I figured the same...I thought that the code for "everything 7" had
already been installed with the Home package and given a Home, or Pro,
or Ultimate authorization code, Win7 would act accordingly...turning on
and off features. Not so.
After putting in the $77 code, it took about 10 to 15 minutes to
download and install quite a bit of stuff. (No idea what or how much as
the screen was pretty non-informative as the process progressed.) The
process also rebooted twice...good old Windows...just to let me know it
was authentic.
I did find, also, that sys(3050,1) throws an error on the 64-bit Win7
Pro, but not the 32-bit Home or Pro. That was in the SETMEM.PRG routine
that I got from Ed's board years ago. I could be wrong because I didn't
spend a lot of time testing, but it didn't appear that sys(3050) did
anything at all in any of the versions of Win7.
That's why I told you that you'd have to adjust it to set the max memory
at 2 GB (?) since Vista and beyond can go higher. I think I set mine to
just ignore SetMemory's code if the OS() was higher than XP's value.
Not the best fix, but quick fix for now. OR, I used values like 1600000
and 800000 for foreground/background respectively (by force instead of
letting calculations be used).
Alan Bourke
2011-03-07 08:58:42 UTC
Permalink
Post by Mike Copeland
The
process also rebooted twice...good old Windows...just to let me know it
was authentic.
LOL yeah, that probably serves no other purpose than making you think
it's doing something.
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
Rick Schummer
2011-03-10 02:40:09 UTC
Permalink
Not sure about the GDIPLUS.DLL, but I'm using XFRX to write PDF files for reports, and I think it likes having
GDIPLUS.DLL around.<<

Sorry for jumping in late in the game (off the hook busy), but the GDIPlus.DLL is required for the VFP runtimes. Some of
the most queried entries on the Visual FoxPro Wiki is the VFP runtime entries:

http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles~VFP

http://fox.wikis.com/wc.dll?Wiki~VFP8RuntimeFiles~VFP

http://fox.wikis.com/wc.dll?Wiki~VFP7RuntimeFiles~VFP

I also noticed you are not running the latest VFP 9 SP2 runtimes. Build number is: Visual FoxPro 09.00.0000.7423 for
Windows [Feb 23 2009 13:20:28]

This includes the latest hotfixes for a reporting problem.

Rick
White Light Computing, Inc.

www.whitelightcomputing.com
www.swfox.net
www.rickschummer.com
Mike Copeland
2011-03-10 12:10:04 UTC
Permalink
Thanks for the jump...late or not!

I'll check these out when I put some new systems together next week and
let you know the results. Appreciate the input.

Mike
Post by Rick Schummer
Not sure about the GDIPLUS.DLL, but I'm using XFRX to write PDF files for reports, and I think it likes having
GDIPLUS.DLL around.<<
Sorry for jumping in late in the game (off the hook busy), but the GDIPlus.DLL is required for the VFP runtimes. Some of
http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles~VFP
http://fox.wikis.com/wc.dll?Wiki~VFP8RuntimeFiles~VFP
http://fox.wikis.com/wc.dll?Wiki~VFP7RuntimeFiles~VFP
I also noticed you are not running the latest VFP 9 SP2 runtimes. Build number is: Visual FoxPro 09.00.0000.7423 for
Windows [Feb 23 2009 13:20:28]
This includes the latest hotfixes for a reporting problem.
Rick
White Light Computing, Inc.
www.whitelightcomputing.com
www.swfox.net
www.rickschummer.com
[excessive quoting removed by server]
Grigore Dolghin
2011-03-10 12:37:17 UTC
Permalink
You will also need the MSXML 4.0 parser (Vista and Windows 7 come with MSXML
6 and VFP doesn't know how to use it) if you need to use Task Pane.

Download link: http://tinyurl.com/2cjs2bn
Post by Kent Belan
-----Original Message-----
Sent: Thursday, March 10, 2011 2:10 PM
Subject: Re: Windows 7 + VFP9 speed problem
Thanks for the jump...late or not!
I'll check these out when I put some new systems together next week and
let you know the results. Appreciate the input.
Mike
Post by Rick Schummer
Post by Mike Copeland
Not sure about the GDIPLUS.DLL, but I'm using XFRX to write PDF
files for reports, and I think it likes having
GDIPLUS.DLL around.<<
Sorry for jumping in late in the game (off the hook busy), but the
GDIPlus.DLL is required for the VFP runtimes. Some of the most queried
http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles~VFP
http://fox.wikis.com/wc.dll?Wiki~VFP8RuntimeFiles~VFP
http://fox.wikis.com/wc.dll?Wiki~VFP7RuntimeFiles~VFP
I also noticed you are not running the latest VFP 9 SP2 runtimes.
Build number is: Visual FoxPro 09.00.0000.7423 for Windows [Feb 23
2009 13:20:28]
This includes the latest hotfixes for a reporting problem.
Rick
White Light Computing, Inc.
www.whitelightcomputing.com
www.swfox.net
www.rickschummer.com
[excessive quoting removed by server]

John Weller
2011-03-03 17:45:45 UTC
Permalink
Many years ago we had a FPW2.6 app which ran faster with 32Mb of RAM than it
did with 64Mb of RAM. We put this down to memory swapping - could this be
the cause here?

John Weller
01380 723235
07976 393631
Post by k***@gmail.com
We have noticed one thing that may be of interest: We have a client
Post by k***@gmail.com
with a new Win7 system with 12gb memory. It takes a long time to load
but the client states it is many times faster during data entry and
creating reports. My explaination (with no proof) is that our VFP9 SP2
compiled program is loading all the programs and data into memory. We
do open several data files before the first screen shows. Also, our
program does not destroy screens (they are in memory and are
reused) so as you use the program it seems to get faster. Our program
and all the initial data would easily fit into 1gb memory so I can't
explain why 12gb would be that much faster than a similar win7
computer with 4gb. It must be something to do with the operating
system and memory management or hardware.
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work in
VFP 9 at all
Mike Copeland
2011-03-03 20:29:14 UTC
Permalink
John,
It certainly makes more sense than anything else.

I used the SetMem routine (from the Profox board) in all my apps for the
last few years, and for some reason I commented it out at some point.
I'll reactivate it and try...

Nope. Identical results. But, that does validate that VFP isn't actually
using the HDrive for this particular process.

I can try replacing the 4GB of RAM with a 2GB stick and see what that does.

Thanks!

Mike
Post by John Weller
Many years ago we had a FPW2.6 app which ran faster with 32Mb of RAM than it
did with 64Mb of RAM. We put this down to memory swapping - could this be
the cause here?
John Weller
01380 723235
07976 393631
Post by k***@gmail.com
We have noticed one thing that may be of interest: We have a client
Post by k***@gmail.com
with a new Win7 system with 12gb memory. It takes a long time to load
but the client states it is many times faster during data entry and
creating reports. My explaination (with no proof) is that our VFP9 SP2
compiled program is loading all the programs and data into memory. We
do open several data files before the first screen shows. Also, our
program does not destroy screens (they are in memory and are
reused) so as you use the program it seems to get faster. Our program
and all the initial data would easily fit into 1gb memory so I can't
explain why 12gb would be that much faster than a similar win7
computer with 4gb. It must be something to do with the operating
system and memory management or hardware.
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work in
VFP 9 at all
[excessive quoting removed by server]
Malcolm Greene
2011-03-03 20:59:00 UTC
Permalink
John,

What happens if you disconnect your PC from the internet and then
temporarily turnoff your workstations virus/security software?

Does that make a difference?

Malcolm
Mike Copeland
2011-03-03 21:08:18 UTC
Permalink
Malcolm,

Good thought....I run AVAST Anti virus and I had already tried disabling
it. No change.

Also, this box has never had any third party firewalls, like Zonealarm,
that love to get their fingers into everyone's pie. Most of my testing
has been done on a brand new box with Win7 Home 32bit installed.

I also, when the load routine was set to load from a local DBF file,
disabled the network adaptor. No change.

Thanks for the brain cycles!

Mike
Post by Malcolm Greene
John,
What happens if you disconnect your PC from the internet and then
temporarily turnoff your workstations virus/security software?
Does that make a difference?
Malcolm
[excessive quoting removed by server]
Eurico Chagas Filho
2011-03-03 21:25:39 UTC
Permalink
Mike

If u break your EXE into pieces, like running this form as an .exe the problem
goes
away, right ?

If u run your .exe in a compatible XP mode nothing changes ?

Can u find out what is the maximum size of the .dbf that the dbi grid can load
without
problem ?

E.
MB Software Solutions, LLC
2011-03-03 21:21:55 UTC
Permalink
Post by Mike Copeland
John,
It certainly makes more sense than anything else.
I used the SetMem routine (from the Profox board) in all my apps for the
last few years, and for some reason I commented it out at some point.
I'll reactivate it and try...
Nope. Identical results. But, that does validate that VFP isn't actually
using the HDrive for this particular process.
I can try replacing the 4GB of RAM with a 2GB stick and see what that does.
Thanks!
Mike
Just remember that with machines over 2GB, the code in SetMemory.prg may
need to be altered to allow a certain max (2GB?), otherwise it will
error. (I've had this experience, anyway.)
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
Mike Copeland
2011-03-03 21:39:43 UTC
Permalink
Tracy,

Yeah, I'm not sure if MEMLIMIT is still in play or not with VFP9, but I
did try it. No change.

I also have re-enabled the SETMEM routine that adjusts the sys(3050,1&2)
settings...no change. Color me bummed.

Mike
Post by Tracy Pearson
Post by k***@gmail.com
I don't have experience with MySQL so I probably would point to that
as a likely problem. Like most developers we have many clients
converting to Win7 with no problems at all unlike the nightmare we had
with Crapsta.
We have noticed one thing that may be of interest: We have a client
with a new Win7 system with 12gb memory. It takes a long time to load
but the client states it is many times faster during data entry and
creating reports. My explaination (with no proof) is that our VFP9 SP2
compiled program is loading all the programs and data into memory. We
do open several data files before the first screen shows. Also, our
program does not destroy screens (they are in memory and are
reused) so as you use the program it seems to get faster. Our program
and all the initial data would easily fit into 1gb memory so I can't
explain why 12gb would be that much faster than a similar win7
computer with 4gb. It must be something to do with the operating
system and memory management or hardware.
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work in
VFP 9 at all
Tracy Pearson
PowerChurch Software
[excessive quoting removed by server]
Fred Taylor
2011-03-03 21:41:17 UTC
Permalink
Total shot in the dark, but this used to be essential on a Lantastic or a
Novell network. See if changing the .EXE and maybe the .OCX, too, to be
ReadOnly.

Fred
Post by Mike Copeland
Tracy,
Yeah, I'm not sure if MEMLIMIT is still in play or not with VFP9, but I
did try it. No change.
I also have re-enabled the SETMEM routine that adjusts the sys(3050,1&2)
settings...no change. Color me bummed.
Mike
Post by Tracy Pearson
Post by k***@gmail.com
I don't have experience with MySQL so I probably would point to that
as a likely problem. Like most developers we have many clients
converting to Win7 with no problems at all unlike the nightmare we had
with Crapsta.
We have noticed one thing that may be of interest: We have a client
with a new Win7 system with 12gb memory. It takes a long time to load
but the client states it is many times faster during data entry and
creating reports. My explaination (with no proof) is that our VFP9 SP2
compiled program is loading all the programs and data into memory. We
do open several data files before the first screen shows. Also, our
program does not destroy screens (they are in memory and are
reused) so as you use the program it seems to get faster. Our program
and all the initial data would easily fit into 1gb memory so I can't
explain why 12gb would be that much faster than a similar win7
computer with 4gb. It must be something to do with the operating
system and memory management or hardware.
I wonder if this much memory ends up swapping.
This might be a good reason to change the SYS(3050) settings.
Perhaps your Config.fpw might need the old MEMLIMIT, which may not work
in
Post by Tracy Pearson
VFP 9 at all
Tracy Pearson
PowerChurch Software
[excessive quoting removed by server]
Alan Bourke
2011-03-03 15:29:18 UTC
Permalink
Mike

I deal with a large VFP9 application that is installed on thousands of
sites, and we are seeing occurrences of this also, to the extent where a
customer will bring in a new Windows 7 machine and it will be extremely
slow, with the other 5-year-old XP machines on the network being fast at
the same operations.

This application has EXE and supporting files locally on the clients,
accessing data on a server share.

My suspicion is that this is due to the different network stack in
Windows 7, crappy Windows 7 drivers for network cards, differences in
the way it negotiates with network hardware, or a combination of these.

I don't have one of these problem sites near me to investigate at the
minute unfortunately.

If you have a Windows Server 2008 in the mix you definitely need to
either set the server to use SMB1 over SMB2, or alternatively apply the
SMB2 hotfix that MS released recently. This will stop index corruption
issues at the very least.

There is also talk that turning off Remote Differential Compression may
help, see here:

http://serverfault.com/questions/85965/slow-network-file-copy-on-windows-7
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
Paul Hill
2011-03-03 15:39:37 UTC
Permalink
Post by Alan Bourke
If you have a Windows Server 2008 in the mix you definitely need to
either set the server to use SMB1 over SMB2, or alternatively apply the
SMB2 hotfix that MS released recently. This will stop index corruption
issues at the very least.
This is supposibly fixed in Windows 7 SP1. Can anyone confirm?
I'm waiting for this to come over my WSUS update server, but it looks
like MicroSoft haven't released it to this channel yet.
--
Paul
Mike Copeland
2011-03-03 19:22:50 UTC
Permalink
Alan,

MANY thanks for your time to send the info below!!!

One puzzler....why is the same routine slow when the code only has to
load from a 23,000 record DBF file that is local (in the same folder as
the EXE)?

I tried by commenting out all the code that fetched the data from the
server, created a simple "SKU.DBF" file with one field, SKU. Saved
SKU.DBF in the same folder as the EXE and loaded the data with:

----------------------------------
use sku in 0
select sku from sku into array laSKU order by sku
use in select('sku')
for nnum=1 to alen(laSKU)
thisform.ctGrid.addcomboitem(1, laSKU(nnum))
endf
-----------------------------------

The above is about 4 seconds faster, but still takes 75 to 76 seconds.

And, according to the profiler, the slowest step in the above is the
"addcomboitem" method.

I have contacted DBI (creator of the ctGrid) and they claim they can not
recreate the problem. I've tried creating a small, 1 form EXE file that
only does the ctGrid and load, and OF COURSE IT IS FAST. The exe is only
48kb.

I suspect it has something to do with my app being 6Mb and somehow that
is creating issues with VFP9's memory management.

Mike
Post by Alan Bourke
Mike
I deal with a large VFP9 application that is installed on thousands of
sites, and we are seeing occurrences of this also, to the extent where a
customer will bring in a new Windows 7 machine and it will be extremely
slow, with the other 5-year-old XP machines on the network being fast at
the same operations.
This application has EXE and supporting files locally on the clients,
accessing data on a server share.
My suspicion is that this is due to the different network stack in
Windows 7, crappy Windows 7 drivers for network cards, differences in
the way it negotiates with network hardware, or a combination of these.
I don't have one of these problem sites near me to investigate at the
minute unfortunately.
If you have a Windows Server 2008 in the mix you definitely need to
either set the server to use SMB1 over SMB2, or alternatively apply the
SMB2 hotfix that MS released recently. This will stop index corruption
issues at the very least.
There is also talk that turning off Remote Differential Compression may
http://serverfault.com/questions/85965/slow-network-file-copy-on-windows-7
Loading...