VFP9 speed issues with better spec PC

[cliffhead]

Not sure if any others have come across this or can offer advice.

I have a product written in VFP9 and we have been seeing speed issues recently. We believed that this was down to Windows 7 being different to XP in terms of the way it communicates with the server.

After testing, it appears that the better spec the client PC, the performance seems to be slower (strange I know).

Example - running a particular process is quicker on a PC with 2GB RAM compared to the the same PC running 4GB RAM.

We have not identified the root cause of the difference in speed but why would a better spec PC be slower - Any ideas?

 

[Mike Lewis]

Cliffhead,

Your observations are correct. I agree that it seems strange, but there are cases where the more memory you given a VFP application, the worse the performance.

There are some tweaks that you can apply to reduce this effect. However, you will need the source code - and the ability to rebuild the application. Is that a problem? The reason I ask is that you say that you have acquired the application, which sounds like you don't have in-house VFP developers.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[JRB-Bldr]

A piece of code that I use to 'tweak' VFP memory utilization, like Mike references above, incorporates 3 different methods.

NOTE - I have not taken the time to deeply investigate if there is REALLY any difference in the results of the differing methods nor if one method negates the results of another.

FUNCTION FreeMemory
LOCAL lnAvailableMem, lpMemoryStatus, lnPct

* --- Approach 1 ---
DECLARE GlobalMemoryStatus IN Win32API STRING @lpMemoryStatus

lpMemoryStatus = REPLICATE(CHR(0), 32)
GlobalMemoryStatus(@lpMemoryStatus)

lnAvailableMem = CharToBin(SUBSTR(lpMemoryStatus, 13, 4))

lnPct = 1
IF TYPE("goApp.nSetMemoryPct") == "N"
   lnPct = goApp.nSetMemoryPct
ENDIF

* --- Approach 2 ---
DECLARE INTEGER SetProcessWorkingSetSize IN kernel32 AS SetProcessWorkingSetSize  ;
   INTEGER hProcess , ;
   INTEGER dwMinimumWorkingSetSize , ;
   INTEGER dwMaximumWorkingSetSize
DECLARE INTEGER GetCurrentProcess IN kernel32 AS GetCurrentProcess
nProc = GetCurrentProcess()
bb = SetProcessWorkingSetSize(nProc,-1,-1)

* --- Approach 3 ---
SYS(1104)
SYS(3050, 1, lnAvailableMem)
SYS(3050, 2, (lnAvailableMem/2) )

RETURN .T.

* ---------------------------------
FUNCTION CharToBin (tcWord)
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

However, like Mike says, you would need to modify your application's source code to utilize this routine (or a part of it) and then re-compile your EXE.

Good Luck,
JRB-Bldr

 

[SnyAc]

Another issue with Windows 7 that affects performance across a network is the OpLocks setting on the server and workstations...

The following links are from Microsoft...

http://support.microsoft.com/kb/296264/en-us

http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

The SMB (Server Management Block) handling has been changed/updated in Windows 7 / Server 2008.


Andy Snyder
SnyAc Software Services

http://www.snysoft.com

Hyperware Inc. a division of AmTech Software

http://www.hyperwareinc.com

 

[Olaf Doschke]

To add to the OpLock issue: There is a Hotfix and this is now included in SP1, so applying Service Pack 1 to Win7 should solve that problem. I couldn't try, that myself, though.

Hotfix:

http://support.microsoft.com/kb/2028965/en-us

SP1:

http://windows.microsoft.com/en-US/windows7/learn-how-to-install-windows-7-service-pack-1-sp1

Setting Memory via SYS(3050) is also a good thing. Half available ram is what VFP does automatic, but 1 GB on a 2GB system is way too much, also 2GB on a 4GB system. This does put an overhead on memory management. The Runtime needs ~10MB, you know what size your exe is and what size you expect for graphics and cursors or memvars. 100 MB should be fairly enough. Setting this as "low" does not mean you/foxpro can't allocate more memory later, if needed, so today I'd use fixed values of 64 MB for each foreground and background processing memory and only make that lower on very old systems with less free RAM.

Bye, Olaf.