Clark,
I'm not certain, but I would think the only good reason to turn off
Rushmore optimization is if you are working with really large tables and
writing complex queries against them. I say this because one of the
features of Rushmore is to build an in-memory bitmap of matching
records. I could see on large tables where the bitmap(s) would require
too much memory, requiring VFP to do lots of extra work just to make
room for the bitmaps.
Another idea that comes to mind is if you have non-discriminating
indexes. In this case, Rushmore would choose to use the indexes but they
would be more of a burden than a help. However, a better choice would be
to drop these indexes instead.=20
Just ideas from the top of my head. I've never seen a reason to turn it
off in my experience.=20
-Chuck Urwiler, MCT, MCSD, MCDBA
http://www.eps-software.com=20
-----Original Message-----
From: White, Clark [mailto:WhiteC@jsc.mil]=20
Sent: Friday, September 13, 2002 9:23 AM
To: Multiple recipients of ProFox
Subject: VFP6: Rushmore/Network Performance
I have found a lot of interesting information on removing the deleted()
index tags to improve performance on a network.
Has anyone on the list ever tried using the NOOPTIMIZE clause to turn
Rushmore off to increase performance? If so, does this help at all?
Clark
I have found a lot of interesting information on removing the deleted()
index tags to improve performance on a network.
Has anyone on the list ever tried using the NOOPTIMIZE clause to turn
Rushmore off to increase performance? If so, does this help at all?
Clark
On Friday, September 13, 2002, at 09:23 AM, White, Clark wrote:
> I have found a lot of interesting information on removing the
> deleted() index tags to improve performance on a network.
>
> Has anyone on the list ever tried using the NOOPTIMIZE clause to turn
> Rushmore off to increase performance? If so, does this help at all?
It could, if you have lots of poorly-designed indexes. But you simply
can't beat Rushmore for queries that are highly discriminate; e.g,
searching for a PK or even a last name.
___/
/
__/
/
____/
Ed Leafe
Yeah, but "dropping indexes" is a tough decision when you have users who are
used to dynamically sorting records in a list by every header that appears.
I will definitely test removing the deleted() flag. According to the
articles, this will kill my main query builder because it does the
following:
1. Asks the user for the criteria
2. Counts the records that meet the entered criteria.
3. Display the criteria (if the user selects view results).
The performance is OK but I am always trying to improve it. I am also not
working with the best network in the world. I was just wondering if there
was a way that I could easily use the benefits of Rushmore without its
drawbacks.
-----Original Message-----
From: Chuck Urwiler [mailto:chuck@eps-software.com]
Sent: Friday, September 13, 2002 10:03 AM
To: Multiple recipients of ProFox
Subject: RE: VFP6: Rushmore/Network Performance
Clark,
I'm not certain, but I would think the only good reason to turn off
Rushmore optimization is if you are working with really large tables and
writing complex queries against them. I say this because one of the
features of Rushmore is to build an in-memory bitmap of matching
records. I could see on large tables where the bitmap(s) would require
too much memory, requiring VFP to do lots of extra work just to make
room for the bitmaps.
Another idea that comes to mind is if you have non-discriminating
indexes. In this case, Rushmore would choose to use the indexes but they
would be more of a burden than a help. However, a better choice would be
to drop these indexes instead.
Just ideas from the top of my head. I've never seen a reason to turn it
off in my experience.
-Chuck Urwiler, MCT, MCSD, MCDBA
-----Original Message-----
From: White, Clark [mailto:WhiteC@jsc.mil]
Sent: Friday, September 13, 2002 9:23 AM
To: Multiple recipients of ProFox
Subject: VFP6: Rushmore/Network Performance
I have found a lot of interesting information on removing the deleted()
index tags to improve performance on a network.
Has anyone on the list ever tried using the NOOPTIMIZE clause to turn
Rushmore off to increase performance? If so, does this help at all?
Clark
On Friday, September 13, 2002, at 10:03 AM, Chuck Urwiler wrote:
> Just ideas from the top of my head. I've never seen a reason to turn
> it off in my experience.
The reason given for providing SET OPTIMIZE OFF is for dynamically
changing data, where your index cache might be out of date. Turning off
Rushmore forces VFP to look at the table itself, not a cached copy of
an index.
___/
/
__/
/
____/
Ed Leafe
I thought the SET OPTIMIZE OFF was for consultants to use until the users
complain that the app is too slow. Then the consultant can charge some more
them to take out the commands.
-----Original Message-----
From: Ed Leafe [mailto:ed@leafe.com]
Sent: Friday, September 13, 2002 10:46 AM
To: Multiple recipients of ProFox
Subject: Re: VFP6: Rushmore/Network Performance
On Friday, September 13, 2002, at 10:03 AM, Chuck Urwiler wrote:
> Just ideas from the top of my head. I've never seen a reason to turn
> it off in my experience.
The reason given for providing SET OPTIMIZE OFF is for dynamically
changing data, where your index cache might be out of date. Turning off
Rushmore forces VFP to look at the table itself, not a cached copy of
an index.
___/
/
__/
/
____/
Ed Leafe
Oh you wanted it faster? Well for an NOMINAL fee I can fix that by
tomorrow. I just have to push that turbo button on your server in. hehehehe
Stephen Russell
Developer - Clinical Research Shared Resource
St. Jude Children's Research Hospital
Mail Stop 504
332 North Lauderdale St.
Memphis, TN 38105
(901) 495-3807 - Office
(901) 246-0159 - Cell
-----Original Message-----
From: Crooks, David L. [mailto:croodl@ispec.com]
Sent: Friday, September 13, 2002 10:13 AM
To: Multiple recipients of ProFox
Subject: RE: VFP6: Rushmore/Network Performance
I thought the SET OPTIMIZE OFF was for consultants to use until the users
complain that the app is too slow. Then the consultant can charge some more
them to take out the commands.
-----Original Message-----
From: Ed Leafe [mailto:ed@leafe.com]
Sent: Friday, September 13, 2002 10:46 AM
To: Multiple recipients of ProFox
Subject: Re: VFP6: Rushmore/Network Performance
On Friday, September 13, 2002, at 10:03 AM, Chuck Urwiler wrote:
> Just ideas from the top of my head. I've never seen a reason to turn
> it off in my experience.
The reason given for providing SET OPTIMIZE OFF is for dynamically
changing data, where your index cache might be out of date. Turning off
Rushmore forces VFP to look at the table itself, not a cached copy of
an index.
___/
/
__/
/
____/
Ed Leafe
----- Original Message -----
From: "White, Clark" <WhiteC@jsc.mil>
To: "Multiple recipients of ProFox" <profox@leafe.com>
Sent: Friday, September 13, 2002 4:21 PM
Subject: RE: VFP6: Rushmore/Network Performance
> Yeah, but "dropping indexes" is a tough decision when you have users who
are
> used to dynamically sorting records in a list by every header that
appears.
> I will definitely test removing the deleted() flag. According to the
> articles, this will kill my main query builder because it does the
> following:
>
> 1. Asks the user for the criteria
> 2. Counts the records that meet the entered criteria.
> 3. Display the criteria (if the user selects view results).
>
You can create indexes on the fly on a view result. User clicks on grid
column header. If theres' no index it's created, else it's activated with
SET ORDRER . DoubleClick it swaps between SET ORDER TO .. DESCENDING to
ASCENDING
-Anders
Oh well, SET CLIPPER ON was a lot better than SET DBASE-III ON
Come to think of it, I still have a multi user Clipper application out
there, last compiled 8/24/1993. By now the user has accepted the fact
that there won't be any upgrades.
Scott
> in the earlier days I told my students
> SET OPTIMIZE OFF is equal to
> SET PERFORMANCE TO CLIPPER or
> SET CLIPPER ON
> <eg>
> Servus
> wOOdy
Author: =?iso-8859-1?Q?J=FCrgen_Wondzinski?=
Posted: 2002-09-16 15:18:18 Link
Hi David,
in the earlier days I told my students:
SET OPTIMIZE OFF is equal to
SET PERFORMANCE TO CLIPPER or
SET CLIPPER ON
<eg>
Servus
wOOdy
|\_/| ------ ProLib - programmers liberty ---------
(.. ) Unsere 3 MVPs bringen den Fuchs zum Laufen...
- / auf www.prolib.de und www.AFPages.de
-----Original Message-----
From: profox@leafe.com [mailto:profox@leafe.com] On Behalf Of Crooks,
David L.
Sent: Friday, September 13, 2002 5:13 PM
To: Multiple recipients of ProFox
Subject: RE: VFP6: Rushmore/Network Performance
I thought the SET OPTIMIZE OFF was for consultants to use until the
users
complain that the app is too slow. Then the consultant can charge some
more
them to take out the commands.