FoxPro Help and Support - Ideal specification for VFP7.0 machine

Author

Ideal specification for VFP7.0 machine

Barley Man

2005-05-28, 8:24 pm

I am forced to work with what are, for me, HUGE record sets (3.6 million
record files). For the first time ever, I am finding Foxpro SLOW! What is the
best way to impove fox's performance by improving the hardware (yes, I do
know that improved coding works best but I still need to know the hardware
side as well)?

In what order should I seek to uprate my machine so that will I receive
improved performance:-

CPU speed?
Hard Drive speed?
Cache?
Ram?
Make of Chip (amd, intel?)
Type of motherboard

...... and what would be a good specification 'combination' machine?

Secondly, when 'merging' two huge files, the disk is clattering wildly. Does
this imply that it would be better to have each of those files on separate
physical drives?

Ian

Olaf Doschke

2005-05-29, 7:24 am

Hi Ian,

Like any other database foxpro will mostly
benefit of fast hard drives and if the tables
are on a file server a fast network. cpu speed
or brand are not very important. Bigger RAM
could speed up working with huge datasets. You
should set ram usage with sys(3050) for bigger
RAM usage, but that only helps if working with
such huge datasets, otherwise would only waste
RAM.

> Secondly, when 'merging' two huge files, the disk is clattering wildly. Does
> this imply that it would be better to have each of those files on separate
> physical drives?
Maybe, give it a try. Maybe it's antivirus
software working on the modified dbf
file(s). And if you have referential integrity
append from dbf()... will cause an insert
trigger for each appended record which
also causes much clattering, if the table
appended to has some relations.

Bye, Olaf.

Paul Pedersen

2005-05-29, 8:24 pm

RAM and more RAM.

Also, make sure your disk has lots of continguous free space. Defragment
and/or replace as necessary.

If you have antivirus, make sure it ignores dbf, cdx, fpt.

Faster CPU is always good, but RAM is probably more important.

My guess is that AMD vs Intel doesn't matter that much, as long as they're
both in the same class.

You're right that the software should be fixed first, though. Indexes where
appropriate, and not where not. Don't handle large sets when small ones will
do. INSERT instead of APPEND.

"Barley Man" < BarleyMan@discussion
s.microsoft.com> wrote in message
news:7E033D44-32DD-4360-8D83- 1775EC845D67@microso
ft.com...
>I am forced to work with what are, for me, HUGE record sets (3.6 million
> record files). For the first time ever, I am finding Foxpro SLOW! What is
> the
> best way to impove fox's performance by improving the hardware (yes, I do
> know that improved coding works best but I still need to know the hardware
> side as well)?
>
> In what order should I seek to uprate my machine so that will I receive
> improved performance:-
>
> CPU speed?
> Hard Drive speed?
> Cache?
> Ram?
> Make of Chip (amd, intel?)
> Type of motherboard
>
> ..... and what would be a good specification 'combination' machine?
>
> Secondly, when 'merging' two huge files, the disk is clattering wildly.
> Does
> this imply that it would be better to have each of those files on separate
> physical drives?
>
> Ian
>

Thomas Ganss

2005-05-30, 3:24 am

Barley Man schrieb:

> In what order should I seek to uprate my machine so that will I receive
> improved performance:-
>
> CPU speed?
> Hard Drive speed?
> Cache?
> Ram?
> Make of Chip (amd, intel?)
> Type of motherboard
>
> ..... and what would be a good specification 'combination' machine?

Depends VERY much on the coding style of the slow parts in your app <g>.
Base rule: if the bottleneck is encountered when using SQL and/or
Rushhmore optimized statements, more RAM is probably helpful.

If you are using old xBase style coding, more/faster disks will help more.
>
> Secondly, when 'merging' two huge files, the disk is clattering wildly. Does
> this imply that it would be better to have each of those files on separate
> physical drives?

Use different disks for reading and writing, if most of the records are
included. Having more than a few disks can be helpful if your tables and
access steps are clearly separated. But most of the times changes to
internal programming logic will give you better results.

First step to see where the HW bottle neck is should be Task manager,
and then probably PERFMON. The best factor I got throwing hardware at
problems was around 15 (very special case) and usually is
between 1 and 3.

HTH

thomas

Sponsored Links