>Hi Vlad,
>As you also said if it can not use an index tag than it is not Rushmore optimizable.
>Rushmore is a method that takes your expression and checks it against your existing tags,
>if one is found it uses this tag, right ?

Right. And (sorry to tell you) this is the only statement I agree in your message. This is what FoxPro does, in order to evaluate what it can be optimized. After that, it builds some bit arrays (in fact, AFAIK, they are already built) and applies fast search algorithms on these arrays. Don't ask me more details, because I don't know more. What I really know about Rushmore optimization is that it works extremly well and that it increases the speed by tens to thousands times.

>Now if you have many tags, checking for a match has an overhead before actual search.

That is done extremly fast, so, you you don't care about it.

>If you use alrady optimized (by yourself of course) expressions you know the tag,
>than why you should use Rushmore, set order by yourself, it is faster, just add another line of code.

Wrong. If you read carefully the docs on Rushmore, you will find a recommendation to not set an order if you want to have good speed with Rushmore. This has a very simple explanation. When you work with an order set on your table(s), you don't (and you can't) take care of FoxPro internal caching and network packaging. But when you let FoxPro do the job of optimization, FoxPro can use a lot more info on how the data is stored, cached, transmitted on the network, etc. This is my explanation. :) Based on the fact that, even with full Rushmore optimization, if you don't set an order you can increase the speed up to 25-30 times!

>A neat example ;
>You have 100000 records containing addresses, you have, say 100 tags. You wan't to get all persons
>with Lastname = "Jones". Unfortunately you have a tag on Lastname + Firstname but not just on Lastname.
>How would you set the expression ? Of course as Lastname+Firstname = "Jones", right ?

This is not a good sample:
1. You don't have an index on Lastname. In your sample you must have SET EXACT OFF" and this can result in wrong record selection. (Any lastname starting with "Jones" will be selected.)
2. I don't expect to select 5% of records when I look for one last name. What if I look for "Tatavu"? :)

>This would be the case with or without Rushmore.
>Without Rushmore
> set order to tag lfname && tag with key lastname+firstname
> =seek("Jones")
> scan while Lastname = "Jones"
> * do nothing or whatever you want
> endscan
>With Rushmore
> scan for Lastname + Firstname = "Jones"
> * do nothing or whatever you want
> endscan
>
>With Rushmore you need fewer lines, but those 2 extra lines execute absolutely faster if your tag is not

Not at all. The internal Rushmore optimization is fast enough to not care about it. You don't need to optimize what is before the scan, but what is inside. Anyway, you don't need to optimize from 1 ms to 0.1 ms for something that is done only once.

>one the first few tags. Fewer the records you benefit more for those extra lines.
>The first example *without Rushmore* executes faster (sometimes more than 400%).

Sometimes, yes. See my comment at the end of the message.

>Rushmore technique could only be better if you could preassume the queries and set your index tags creation
>order for a special purpose, keep your tags a few etc.
>The more the tags Rushmore method is slower. Worst if the tag you will be using created last.

As I said, this is really not important.

>So in reality who is optimizing way it works, Rushmore or the way you write your code ?

Final comments:
1. Why do you think that FoxPro is still the fastest tool in its domain? Why do you think that all FoxPro developers try to get the maximum from Rushmore? Just to save one or two commands here and there in their programs? No. Because Rushmore is the one that empowers our programs and makes them so fast. I just can't believe everybody's wrong!

2. Read again all the docs on Rushmore. When you understood them really well and you know the rules, do some tests. On tables with more than 10-20,000 records, when the selected set of records is at least 2-5% of the whole table. Of course, with and without Rushmore. I bet whatever you want that Rushmore is faster. And if it's not faster in one of your test, try to see why. Ask here. Usually, it's almost impossible to beat Rushmore. Believe me, I've run hundreds of tests on all kind of tables/situations.

3. I don't really understand why you want to optimize something that can be optimize internally by FoxPro. Why do you want to do a job that can be done automatically? The computer and the dev tools are here to help us, so we must use them at their power. I will give you a classical example from C: you can divide an integer by 2 in two ways: using the usual divide operator or by shifting to the left with one binary position. Which one is better? The first one is more clear (and the risk for bugs is smaller), the second one is faster. Which one should be used? Answer: the first one. The logic: it's almost impossible to make an error when you divide by 2, but it's a big chance you may have a bug when you use the shift operation (shift to the right, shift 2 positions, etc). The program will be more readable. More than that, if your compiler doesn't optimize automatically such a simple operation (ie it should generate the shift operation automatically), you better change the compiler. It's just not good enough for you. So, don't try to do the job that can be done by your tools automatically. Let them do it. This is what the computer is for. :) I think you got the point: don't try to set the order for optimization in FoxPro. FoxPro is smart enough to choose the best order to use. (This doesn't mean it will set that order.)

4. If you select just several records from a small table, FoxPro is fast enough to do it fast (almost:)) whatever you do. If all tables are small, you usually don't care and don't need optimizations. So, why not write programs that are optimized? Your programs will be fast even when the tables will grow. And if they don't grow, the program will stay fast!

Instead of conclusions:
1. Use Rushmore as often as you can. When even Rushmore is not fast enough, try to see why, look for alternative solutions, database reorganisation, different algorithms, etc.

2. Don't use Rushmore where there's no need for it (ie don't use a SCAN instead of a SEEK !:)). Rushmore is not a panacea! :)

Regards,
Vlad