FoxPro 2.6 way too slow under Windows XP/2000

[filibuster]

Hi all,

a foxpro 2.6 (windows) application which is fast on Windows 9x and Windows NT machines is much slower on Windows XP/2000 boxes, even if those computers are better in terms of memory and CPU.

It does not make a difference whether the application is started from the local hard drive or whether it is run from a network drive.

We've played around with the video adapter (true color vs. medium color, screen resolution & video acceleration), but nothing helped.

I've scanned this forum and found quite a few articles which seem to talk about this problem but I haven't found any solution.

Any ideas ?

Rgds
Fili


PS: just for the record:

thread182-121294

 

[rgbean]

Since the last time FPW was updated was before Win9x, Win200 or XP were even being developed, why would you think these OSs would be optimal for running it? Have you considered upgrading to VFP - one version or another has been around now for 7+ years now. (Actually 4 versions, soon to be 5!)

On the other hand, it's NOT been my experience that FPW apps run "slower" on my XP box. Is there some speciifc process that is giving you trouble? If you are making a lot of API calls either directly through FoxTools or some FPW routines, you may be suffering all the 16-bit to 32-bit "thunking" necessary to call those routines that have 32-bit equivalents. Remember FPW was written for use in Win 3.x - a 16-bit OS.

Rick

 

[Iefke]

Have you checked the CPU-usage?
Im running FP2.6 applications on a lot of machines with all versions of Windows and different amounts of memory. In my expierince, On Win2K and XP they all run fine, as long as they are the only 16bit application. Starting a DOS application at the same time slows them down because the DOS-application i use eats up almost all the CPU-cycles. The absolute slowdown is running Word97 at the same time. What helped me alot is running all 16bit applications in their own ntvdm and using TameDOS (

http://www.tamedos.com)

to 'tame' the DOS-apllications. I still have to do additional tests, but TameDOS maybe will help with 16bit-Windows applications too.

Kind Regards,
Yvo

 

[ramani]

HI

1. Have you checked the memory usage allowed to this application?

Often I have noticed, that the settings are not optimal under these OS by default. You have to tweak.

You can include the following lines of code and check the status.

*****************************************************
CLEAR
@ 4,7 SAY "Fox Pro Version.....: "+VERSION()
@ 5,7 SAY "Operating System....: "+OS()
@ 6,7 SAY "Hardware in use.....: "+SYS(17)+' '+SYS(2006)
@ 2,0 FILL TO 7,76 COLOR SCHEME 5
@ 9,7 SAY "Total Memory (RAM)..: " ;
+LTRIM(STR(VAL(SYS(1001))/1024,9,1))+' Kb'
@ 10,7 SAY "DOS Memory available: " ;
+LTRIM(STR(MEMORY()))+' Kb'
@ 11,7 SAY "Currently Used .....: "+ ;
LTRIM(STR(VAL(SYS(1016))/1024,9,1))+' Kb'
@ 8,0 FILL TO 12,76 COLOR SCHEME 1
@ 14,7 SAY "Default Drive ......: "+SYS(5)
@ 15,7 SAY "Total Disk Space....: " ;
+STR(VAL(SYS(2020))/1024000,6,2)+' Mb'
@ 16,7 SAY "Available Disk Space: "+ ;
STR(DISKSPACE()/1024000,6,2)+' Mb'
@ 13,0 FILL TO 18,76 COLOR SCHEME 7

WAIT SPACE(7)+"Press any key to EXIT "
CLEAR
******************************************

If you see that you are running extended version and that you have a large Total memory, then the speed is for some other reason. There is some speed improvement if the total harddisk space is more. (This is OS reuirement).

Hope this helps you to probe
ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[filibuster]

Hi guys,

thanks for your responses

>Since the last time FPW was updated was before Win9x, Win200 or XP were even being developed, why would you think these OSs would be optimal for running it? Have you considered upgrading to VFP - one version or another has been around now for 7+ years now. (Actually 4 versions, soon to be 5!)

I know. But it has not been my decision to stay with this old crap.

CPU Usage, Memory usage and I/O seem to be o.k. - we were checking the Windows XP performance monitor last night. I mean IT SEEMS, there is a lot of room for misinterpratation for those statistics.

We will do some profiling today to find out if it is specific functions that are taking long. I'll keep you updated.

 

[filibuster]

another note: The same app runs fast on some Windows 2000 machines, but slow on others (different installations/customers, but same app).

 

[DSummZZZ]

Yet another note, if you have some sort of anit-virus running you should try setting it to not scan files associated with your app. Escpecially .DBFs, .CDXs, .FRTs, and so on. AV will scan these files as you are trying to access them.
Dave S.

 

[filibuster]

Thanks. there is no Antivirus software running on the PCs.

So far we have tried the following without success:
- changed the video driver to standard vga (640x480)
- updated windows 2000 with latest service pack
- recreated forsuer.dbf
- set up temp directories
- played around with MEMLIMIT and MVCOUNT

In general the problem can be specified in more detail as follows:
- the program is slow when closing screens (e.g. .spr-Files, generated by GENSCRN)
- the rest of the program is o.k.
- on the command line, MODIFY COMMAND and MODIFY FILE are slow as well
- is is slow both on network (novell netware) and local drives

We have also done very simple some profiling (usint WAIT WINDOW) and found out the following:
- when closing a screen, the time between pressing ESCAPE and READ CYCLE NOLOCK is about 3 sec.
- the time spend in the deactivate() function is minimal
- it does not make a difference whether the screen is simple or not

Any ideas ?

PS: In case anyone is interested, I created another thread regarding this problems on experts-exchange.com:

http://www.experts-exchange.com/Databases/FoxPro/Q_20386957.html

 

[filibuster]

Hi all,

thanks a lot for your input. I'm out for the weekend now, so I might not be able to answer any posts until monday.

Live long and prosper
Fili

 

[Grimwaldi]

I use both DOS and WIN 2.6a and I had a total stop when a XP box was added to the network (Novell 4.5). I gave it go trying to tweek it, but I gave in an our network contractor came in. He down loaded some patches for the Novell network and changed many settings on the server. This still didn't help, until he checked some of the switches. They were at fault. The Utilisation (on the server) went from 25% down to 2% (10% is high). Please check your server,network cards. Even on a standalone you are still plugged in unless you pull the cord out.

We still had problems with the PC so I loadded 15 copies of the DOS app at the same time to check for speed and they worked ok, so there has to be another app that is causing the slowdown. My users say they don't run anything else, but who believes users.

Hope this helps

 

[snix2]

Hi. We had exactly the same issues with our software, and found it was the foxpro FLUSH command that is causing the slowdown. At regular intervals in our code, we used FLUSH to save changes to the databases.

To resolve, we placed the FLUSH commands less frequently and more strategically!

 

[Nigel Gomm]

try SET AUTOSAVE OFF