VFP7 very slow performance

I am looking at speed problems that one of our application users has
reported. Basically the problem is happening on very large tables of around
100,000 records. Each record has around 40 fields. All fields are indexed
as a rule in our application. The speed issues are mainly over a network
although it is also noticeably slow on my c: drive.
I've analysed the problem using SET COVERAGE and have found that on saving a
new record to one of these tables, the Tableupdate takes about 1 second but
the application pauses for 16 seconds on the END TRANSACTION line. I have no
idea how to improve the speed of this so any clues would be most helpful.

Bernie

Ook
Sat Sep 18 12:06:49 CDT 2004

The problem is most likely that you have all fields indexed. This is a very
bad design, and is almost never necessary. Get rid of unnecessary indexes,
and you will probably see very significant performance inpromvements.


"Bernie Beattie" <BernieBeattie@discussions.microsoft.com> wrote in message
news:4004B2A6-F3B2-4E90-BAD2-DB5497FAB011@microsoft.com...
>I am looking at speed problems that one of our application users has
> reported. Basically the problem is happening on very large tables of
> around
> 100,000 records. Each record has around 40 fields. All fields are
> indexed
> as a rule in our application. The speed issues are mainly over a network
> although it is also noticeably slow on my c: drive.
> I've analysed the problem using SET COVERAGE and have found that on saving
> a
> new record to one of these tables, the Tableupdate takes about 1 second
> but
> the application pauses for 16 seconds on the END TRANSACTION line. I have
> no
> idea how to improve the speed of this so any clues would be most helpful.
>
> Bernie

Fox/Net
Sat Sep 18 22:25:17 CDT 2004

Since you mentioned over the network.

Check to see if the file server has an active session of a virus scanner
like Norton or McAfee. There are occasions where server virus scanning is
set to "ALL" files versus a more business decision. Virus scanning has the
potential to slow a VFP APP way down.

hth

John Gunvaldson
San Diego, CA


"Bernie Beattie" <BernieBeattie@discussions.microsoft.com> wrote in message
news:4004B2A6-F3B2-4E90-BAD2-DB5497FAB011@microsoft.com...
> I am looking at speed problems that one of our application users has
> reported. Basically the problem is happening on very large tables of
around
> 100,000 records. Each record has around 40 fields. All fields are
indexed
> as a rule in our application. The speed issues are mainly over a network
> although it is also noticeably slow on my c: drive.
> I've analysed the problem using SET COVERAGE and have found that on saving
a
> new record to one of these tables, the Tableupdate takes about 1 second
but
> the application pauses for 16 seconds on the END TRANSACTION line. I have
no
> idea how to improve the speed of this so any clues would be most helpful.
>
> Bernie

Stefan
Sat Sep 18 22:53:24 CDT 2004

See also Sys(3054) to discover Rushmore optimization issues.


hth
-Stefan

"Bernie Beattie" <BernieBeattie@discussions.microsoft.com> schrieb im Newsbeitrag
news:4004B2A6-F3B2-4E90-BAD2-DB5497FAB011@microsoft.com...
>I am looking at speed problems that one of our application users has
> reported. Basically the problem is happening on very large tables of around
> 100,000 records. Each record has around 40 fields. All fields are indexed
> as a rule in our application. The speed issues are mainly over a network
> although it is also noticeably slow on my c: drive.
> I've analysed the problem using SET COVERAGE and have found that on saving a
> new record to one of these tables, the Tableupdate takes about 1 second but
> the application pauses for 16 seconds on the END TRANSACTION line. I have no
> idea how to improve the speed of this so any clues would be most helpful.
>
> Bernie

Leemi
Tue Sep 21 09:27:01 CDT 2004

Hi Bernie:

Along with the other ideas you received, I would add a SYS(3050) function
to the code to optimize VFP's internal memory usage when handling data.
Also, make sure your temp files are directed to a folder on the local
machines hard drive and not the server. (Use the TMPFILES=C:\foldername
switch in the Config.fpw file.)

Here is an article on the SYS(3050) function:

176483 PRB: Large Amounts of RAM Seem to Process Data Slowly
http://support.microsoft.com/?id=176483

By the way, you mentioned an index. You don't have any index tag on the
Deleted() function do you?

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 Public Beta Now Available!! --*
Download the VFP9 beta here: http://msdn.microsoft.com/vfoxpro/

*-- VFP8 HAS ARRIVED!! --*
Read about all the new features of VFP8 here:
http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
Purchase VFP8 here:
http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003


>The problem is most likely that you have all fields indexed. This is a
very
>bad design, and is almost never necessary. Get rid of unnecessary indexes,
>and you will probably see very significant performance inpromvements.


>"Bernie Beattie" <BernieBeattie@discussions.microsoft.com> wrote in
message
>news:4004B2A6-F3B2-4E90-BAD2-DB5497FAB011@microsoft.com...
>I am looking at speed problems that one of our application users has
> reported. Basically the problem is happening on very large tables of
> around
> 100,000 records. Each record has around 40 fields. All fields are
> indexed
> as a rule in our application. The speed issues are mainly over a network
> although it is also noticeably slow on my c: drive.
> I've analysed the problem using SET COVERAGE and have found that on
saving
> a
> new record to one of these tables, the Tableupdate takes about 1 second
> but
> the application pauses for 16 seconds on the END TRANSACTION line. I
have
> no
> idea how to improve the speed of this so any clues would be most helpful.
>
> Bernie

Ook
Tue Sep 21 10:11:46 CDT 2004

Lee, I was under the impression that TMPFILES was not needed with VFP
because it now defaults to the Windows temp directory?


"Lee Mitchell" <Leemi@online.microsoft.com> wrote in message
news:1RVPTc%23nEHA.3312@cpmsftngxa06.phx.gbl...
> Hi Bernie:
>
> Along with the other ideas you received, I would add a SYS(3050) function
> to the code to optimize VFP's internal memory usage when handling data.
> Also, make sure your temp files are directed to a folder on the local
> machines hard drive and not the server. (Use the TMPFILES=C:\foldername
> switch in the Config.fpw file.)
>
> Here is an article on the SYS(3050) function:
>
> 176483 PRB: Large Amounts of RAM Seem to Process Data Slowly
> http://support.microsoft.com/?id=176483
>
> By the way, you mentioned an index. You don't have any index tag on the
> Deleted() function do you?
>
> I hope this helps.
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> Sincerely,
> Microsoft FoxPro Technical Support
> Lee Mitchell
>
> *-- VFP9 Public Beta Now Available!! --*
> Download the VFP9 beta here: http://msdn.microsoft.com/vfoxpro/
>
> *-- VFP8 HAS ARRIVED!! --*
> Read about all the new features of VFP8 here:
> http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
> Purchase VFP8 here:
> http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518
>
> Keep an eye on the product lifecycle for Visual FoxPro here:
> http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
> - VFP5 Mainstream Support retired June 30th, 2003
> - VFP6 Mainstream Support retired Sept. 30th, 2003
>
>
> >The problem is most likely that you have all fields indexed. This is a
> very
> >bad design, and is almost never necessary. Get rid of unnecessary
indexes,
> >and you will probably see very significant performance inpromvements.
>
>
> >"Bernie Beattie" <BernieBeattie@discussions.microsoft.com> wrote in
> message
> >news:4004B2A6-F3B2-4E90-BAD2-DB5497FAB011@microsoft.com...
> >I am looking at speed problems that one of our application users has
> > reported. Basically the problem is happening on very large tables of
> > around
> > 100,000 records. Each record has around 40 fields. All fields are
> > indexed
> > as a rule in our application. The speed issues are mainly over a
network
> > although it is also noticeably slow on my c: drive.
> > I've analysed the problem using SET COVERAGE and have found that on
> saving
> > a
> > new record to one of these tables, the Tableupdate takes about 1 second
> > but
> > the application pauses for 16 seconds on the END TRANSACTION line. I
> have
> > no
> > idea how to improve the speed of this so any clues would be most
helpful.
> >
> > Bernie
>
>
>
>

Anders
Tue Sep 21 11:45:04 CDT 2004

BITMAP=OFF in CONFIG.FPW is or was also recommended.
-Anders

"Ook" <usenet@nospam.emberts.com> wrote in message
news:uaFwP1#nEHA.3896@TK2MSFTNGP15.phx.gbl...
> Lee, I was under the impression that TMPFILES was not needed with VFP
> because it now defaults to the Windows temp directory?
>
>
> "Lee Mitchell" <Leemi@online.microsoft.com> wrote in message
> news:1RVPTc%23nEHA.3312@cpmsftngxa06.phx.gbl...
> > Hi Bernie:
> >
> > Along with the other ideas you received, I would add a SYS(3050)
function
> > to the code to optimize VFP's internal memory usage when handling data.
> > Also, make sure your temp files are directed to a folder on the local
> > machines hard drive and not the server. (Use the TMPFILES=C:\foldername
> > switch in the Config.fpw file.)
> >
> > Here is an article on the SYS(3050) function:
> >
> > 176483 PRB: Large Amounts of RAM Seem to Process Data Slowly
> > http://support.microsoft.com/?id=176483
> >
> > By the way, you mentioned an index. You don't have any index tag on the
> > Deleted() function do you?
> >
> > I hope this helps.
> >
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >
> > Sincerely,
> > Microsoft FoxPro Technical Support
> > Lee Mitchell
> >
> > *-- VFP9 Public Beta Now Available!! --*
> > Download the VFP9 beta here: http://msdn.microsoft.com/vfoxpro/
> >
> > *-- VFP8 HAS ARRIVED!! --*
> > Read about all the new features of VFP8 here:
> > http://www.universalthread.com/VisualFoxPro/News/VFP8Release.asp
> > Purchase VFP8 here:
> > http://shop.microsoft.com/Referral/Productinfo.asp?siteID=11518
> >
> > Keep an eye on the product lifecycle for Visual FoxPro here:
> > http://support.microsoft.com/default.aspx?id=fh;[ln];lifeprodv
> > - VFP5 Mainstream Support retired June 30th, 2003
> > - VFP6 Mainstream Support retired Sept. 30th, 2003
> >
> >
> > >The problem is most likely that you have all fields indexed. This is a
> > very
> > >bad design, and is almost never necessary. Get rid of unnecessary
> indexes,
> > >and you will probably see very significant performance inpromvements.
> >
> >
> > >"Bernie Beattie" <BernieBeattie@discussions.microsoft.com> wrote in
> > message
> > >news:4004B2A6-F3B2-4E90-BAD2-DB5497FAB011@microsoft.com...
> > >I am looking at speed problems that one of our application users has
> > > reported. Basically the problem is happening on very large tables of
> > > around
> > > 100,000 records. Each record has around 40 fields. All fields are
> > > indexed
> > > as a rule in our application. The speed issues are mainly over a
> network
> > > although it is also noticeably slow on my c: drive.
> > > I've analysed the problem using SET COVERAGE and have found that on
> > saving
> > > a
> > > new record to one of these tables, the Tableupdate takes about 1
second
> > > but
> > > the application pauses for 16 seconds on the END TRANSACTION line. I
> > have
> > > no
> > > idea how to improve the speed of this so any clues would be most
> helpful.
> > >
> > > Bernie
> >
> >
> >
> >
>
>