Can FPW 2.6a MEMLIMIT handle MORE than 16384 4

[tamayok]

Hello FoxFriends and Greetings from Puerto Rico, USA!

I am supporting a number of legacy applications which are written in (.esl patched) FPW 2.6a, mostly running under Windows XP Pro and Windows 2000 stations. Eventually, some of these will be upgraded to VFP 8, but for the time being I want to "tweak" the configuration of some of these to increase their usage of memory available under these current setups.

Besides all the typical re-coding and better Rushmore usage, I applied a MEMLIMIT statement to the configuration file. Immedialely, there was a CONSIDERABLE/IMPRESSIVE improvement on queries, etc. However, I would like to enhance it a bit more...

I tried MANY different MEMLIMIT configurations and tested under identical scenarios, and ended with the best times using:

memlimit=60,16384,16384

I also tried settings such as these, but all resulted in inferior (or equal) performance:

memlimit=60,4096,8192
memlimit=60,4096,16384
memlimit=60,8192,16384
memlimit=60,16384,24576
memlimit=60,16384,32768
memlimit=60,32768,32768

Is FPW 2.6a limited to memory usage of 16 megs? Is there ANY workaround to this? Is it OFFICIALLY stated anywhere?

Very curious!!!

 

[rob444]

FPW and FPD are limited to 16MB of memory.
As far as I remember this limit is mentioned in the printed documentation.

Rob.

 

[rgbean]

While I can no longer find the "official" source of the 16MB limit statement, I know that I've often stated it in this and other FPD / FPW forums. (I believe this had to do with DOS and FPD and then Windows 3.x and FPW.) I can report that on my XP system, the FPW Help -> About FoxPro ... -> Total Memory never shows a higher value than 9,544,672 - no matter what I put in the MEMLIMIT. If I put a lower number - say:
memlimit=60,2048,8192
Then I do get a lower number - 8,388,576.

This number is the same as SYS(1001) reports.

On my Win98 SE system,
memlimit=80,2048,16384
gives 16,777,184
AND
memlimit=80,2048,32768
gives 33,554,400
But it doesn't appear to make anything run faster - I think it's just reporting it differently.

Rick

 

[tamayok]

rgbean,

Using FPW 2.6a, I am able to obtain a maximun of 16,877,184 under the "About FoxPro..." form WHILE RUNNING XP.

If you get 9,544,672 under XP/FPW and I get 16,877,184 under XP/FPW... this points to some setting under OS control.

This is an important find...It IMPLIES that the limit is set somewhere OUTSIDE of FPW... otherwise, you would be able to obtain AT LEAST the 16,877,184 report.

(I am limited to that number in spite of changing the configuration MEMLIMIT statement.)

Unfortunately, I now longer have access to any OS prior to Win2000, so I can't test it under Win98.

I looked at the documentation and couldn't find any reference to a memory "ceiling" or mention of 16 mb's.

Some of these apps I am maintaining manage/query millions of records and are large executables... upgrading the MEMLIMIT configuration from 4 to 16 made an ENORMOUS difference... almost unbelievable, I wonder what could 32 megs do...

Intriguing and Important!!! ---- Thanks for your replies... Please keep examining...

 

[tamayok]

Anyone else have some input on this?

 

[Brak]

I messed around with the config on my machine.

I'm running win95b on a 450Mhz.

I had:
MEMLIMIT = 60, 2048, 16384
MVCOUNT = 1024

And was getting ins. mem. errors.

When I changed it to:
MEMLIMIT = 80, 2048, 32768
MVCOUNT = 65000

I quit geting the errors. Happy day for me.

 

[Brak]

Sorry!!!!

I take that back.


I found in my code the array in my pop-up being dime as 1.
When I fixed the code the error came back up.


I found one solution to this problem when using a list, but what about using a popup?


B"H
Brak

 

[DSummZZZ]

Brak,

Off topic, but this thread may help:

Insufficient Memory - Define Popup
thread182-283663



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Brak]

I read your referenced post. I don't know if I quite understand how to implament your code into the pop-up. What should the code look like in the pop-up itself and where does it go in the pop-up, the When or the Valid?

I get the error at and in a strange place.

When the screen is drawn no error is produced. I'm able to use the pop-up and everything. But when I do a SHOW GET on the pop-up I get the ins. mem. error.

Here is the weird thing:

I have my memlimit set to thus:
60, 2048, 16384 - which is confirm on the "About FoxPro"

It says that my total memory is 16,777,184
When the program is running it says that the Memory in use is 596,864. Now unless my math is bad, I should be able to have almost 8 times the memory that is currently being used. So why is it that if I try to show get the one pop-up that I get this error? It just doesn't make sense!


B"H
Brak

 

[rgbean]

Brak,
Like most controls (and program modules) in FPW, a single popup is limited to 65Kb of total memory. The 'problem' may not have anything to do with how much memory you have available. It's rarely a good idea to have a popup with more than 255 items, and that shouldn't ever take up 65Kb of RAM.

Rick

 

[tamayok]

I'm thrilled to get responses to this forum from such a long time ago... My thanks to all!

I guess, in spite of the analysis, still the 16384 MEMLIMITation seems to linger on our good-old FPW 2.6a. If somehow, this limitation could be by-passed...

 

[susn]

I've move a FoxPro 2.6 application from a Win3.x to WinXP OS. One process (writing to a log file) runs much, much slower on XP.
I've tried MANY different MEMLIMIT configurations and tested under identical scenarios, but all resulted in mostly equal performances.


Any thoughts?
Thanks

 

[bobmpalmer]

I have posted this before but my advice is when running on XP do NOT use the third parameter on memlimit it simply causes problems and systems appear to run perfectly happily without it! It is worth noting that MEMLIMIT was provided to LIMIT the amount of memory FoxPro stole from memory managers such as EMM386 etc. Memory is handled in a very much different way on XP and win 2000 and the OS will control how much memory foxpro gets not the other way round so leaving the third parameter off allows the OS to determine whats available. Being that Most systems nowadays have at least 128MB available compared to the paltry 32/64 MB that was around when 2.5 came out it isn't really a problem.

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[rgbean]

susn,
Most of the slowness on newer systems can usually be traced to realtime Virus checkers. Make sure you set the configuration to ignore changes in (at least!) .DBF, .FPT and .CDX files. Developers of course need to add all the "source" files - .PJX, .PJT, .PRG, .H, .SCX, .SCT, .VCX, .VCT, .RPT, .RPT, .LBX, .LBT, .MNX, .MNT, .QPR, etc.

Rick

 

[susn]

I've turned off real-time Virus checker, tested then
tried removing the third parameter on memlimit.
No improvement in performance.

When running a legacy 16 bit application on XP, is there an
option to configure in the DOS layer?
The process of scanning, reading and writing to the disk is what's really slow. What about wow.exe?

Thanks for the help, susn

 

[dbMark]

Susn, there are other issues than MEMLIMIT. See thread182-907896 for more suggestions. Try my suggestion there dated September 1 where I recommend using Command.com rather than Cmd.exe and slide the Dos Idle setting towards the right or just maybe use the Compatibility tab. Or try TameDOS mentioned elsewhere in other threads on this forum.

dbMark

 

[rgbean]

susn,
If it's a FoxPro DOS application, then definitely check out TameDOS. Also, if this is a critical app, you may want to get Virtual PC, load DOS 6.22 in it and run the app in there. This is a much cleaner solution - as long as you don't need any specially hardware attached.

Rick

 

[severach]

I don't know anything about FPW but FPD-386 is not limited to 16MB of RAM. I've had sessions using more than 200MB of ram. I only use FPD-386. The FPD-286 version may be limited to 16MB and for no known reason, FOX.EXE may decide to launch FPD-286 without warning. I delete the autolauncher FOX.EXE and rename FOXPROX.EXE to FOX.EXE since I never want to run FPD-286.

The 2nd and 3rd parameter of MEMLIMIT is limited to 65536KB of RAM. To limit values above that, you must leave out the 3rd parameter of MEMLIMIT and carefully twiddle the % to get the amount of ram desired based on how much Windows reports is free. The Win9x PIF file definition can limit RAM usage above 64MB. You should also use MinFileCache and MaxFileCache in Win9x SYSTEM.INI to ensure that the file cache doesn't artifically lower the free RAM reported. In general, the more Foxpro RAM and less file cache ram improves performance. Executing CacheSet from

http://www.sysinternals.com/ntw2k/utilities.shtml

just before running FOX.EXE will cut the cache size in NT and ensure that lots of memory is available.

I leave my limits at 16MB and kick it up when I have something big to run.

One great cause of slowness in Foxpro applications is when Windows reports all physical RAM as free and Foxpro uses it which forces big operations into the swap file. Twiddle those numbers until Windows & FPD both have enough memory to run without swapping.