Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

memory

Status
Not open for further replies.

Nigel Gomm

Programmer
Jan 10, 2001
423
CA
I just upgraded a customer to a new version of a program and performance suffered badly. i.e. the same forms would take longer to load by a factor of 2 or 3. The difference was only really noticeable when accessing data (native DBC and DBF) over a LAN.

Customer's machines are middling to lower end of the spec range but still adequate. Windows XP.

Using set coverage i could see no obvious places where things were slowing down. And it was claimed (no measurements on this) that my app was slowing down the whole PC.

The new version of the .exe was a quite a big bigger (13.5mb rather than 8.9mb) mainly because i had included some readonly tables and the reports in the project.

So i excluded them, got the .exe down below 9mb again and lo and behold performance was back to as it had been.

This release is ok but i'm now a bit nervous that with future upgrades it won't be so easy to keep the size down.

PROGCACHE and SYS(3050) are default.

Should i be reading up on SYS(3050) ?

nigel

 
Nigel,

If the EXE contained 4 - 5 MB of bound-in tables, that would definitely be a drag on performance. And if the EXE was being run from a file server, that would increase the drag by a big factor.

Do you really need to bind the tables into the EXE?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business
 
Mike,

the included tables were the stonefield coremeta, dbcxreg and stdmeta tables. They are only used to update and repair my tables and not open during normal running. I included them to make sure each version of the program had the correct version of the table definitions.

The executable resides on the local machine.

n



 
Mike,

Any one version of the program may have a dependency on certain new fields being present. When customers restore data from backups they can overwrite the tables (and the definition tables) with earlier versions of the table structures..... so i prefer to keep the tables definitions with the program. (n.b. this is a constantly updated vertical app with well over 500 customers)

My best guess is this is not about the included tables... only the size of the program.

The Help on PROGCACHE says "....the default setting equates to an allocation a little over 9MB." and since 9mb is about the size above which my prog's performance declines this is my next line of investigation.

Any advice would be greatly appreciated.

n
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top