>But very much faster is a scan for command instead of select in some cases.

This last one seems quite logical to me. The fact that a command is "Rushmore Optimized" doesn't mean it is optimal: it still requires quite a lot of work to get the set of records to be processed.

Another speed issue: Commands that use Rushmore Optimization, on the other hand, rely on indices (indexes), and it is easy to believe that any index can help make a query optimal, or at least be neutral. But it is now generally known, for instance, that an index with a tag like deleted(), can slow down your queries considerably, in some cases.

And yet another: in queries for reports, I found it to be usually much faster to divide a multi-table query into several pieces (combine 2 tables, combine the result with a 3rd. table, etc.). When I started to investigate this, I reduced one query, from 50 seconds to 2 seconds, just by splitting it up.


There is one important issue you have to consider. When making speed tests, you have to be very careful of buffering issues. Let's assume you want to compare two commands that access a table:

lnTime = seconds()
* Commands (set 1) to process a table
? seconds() - lnTime

lnTime = seconds()
* Commands (set 2) to process a table
? seconds() - lnTime

If the same table is processed, for the "set 2" part, many of the records can already be in buffers, reducing access time significantly! This led some people to conclude, for instance, that at() was faster than "$". Repeating the test (to eliminate buffering bias) shows that this is not so.


Viele Grüsse,

Hilmar.