Hi Mark,
not really problems, but repeat each variation a few times to eliminate windows memory effects.
Just speculating I'ld expect the best use for binary indices on server tables, reducing the amount of data transferred across the wire.
Even better: simulate a WAN with RAS via a serial cable <g>. Perhaps in these scenarios even filtered selects might be interesting.
On a local machine this effect should be smaller, since the bottleneck is wider.
One thing that I'ld include in my testing is invalidating the buffered .cdx BEFORE each test by writing one record. This is closer to my usage patterns and here the binary might show more "beneficial" effects, but the benchmark should be kept as similar as possible to the real scenario: a read intensive web site would be better simulated by your approach.
"Unpacking" the binary index could take longer than reading a regular one, but a factor of 2 is much more than I would have thought - keep us posted on further findings.

rgds

thomas

>Does anyone see a problem with this? I get a response more the 2x faster using a regular index than the binary index. I see similar results if I change the WHERE clause to "WHERE NOT f2" --

>CREATE CURSOR crsBin (f1 c(2), f2 L)
>FOR lnI = 1 TO 100000
>   lcF1 = ICASE( ;
>            MOD(lnI,4) = 1, 'A', ;
>            MOD(lnI,4) = 2, 'B', ;
>            MOD(lnI,4) = 3, 'C', ;
>            'D')
>   llF2 = IIF(MOD(lnI,50) = 0, .F., .T.)
>   INSERT INTO crsBIn VALUES (lcF1, llF2)
>ENDFOR
>
>SELECT crsBin
>INDEX ON f2 TAG f2tag binary
>lnSeconds = SECONDS()
>SELECT COUNT(*) FROM crsBin WHERE f2 = .f. INTO CURSOR crsResults nofilter
>?
>? [TIME (binary index):], SECONDS() - lnSeconds
>USE IN SELECT('crsResults')
>
>SELECT crsBin
>DELETE TAG f2tag
>INDEX ON f2 TAG f2tag
>lnSeconds = SECONDS()
>SELECT COUNT(*) FROM crsBin WHERE f2 = .f. INTO CURSOR crsResults nofilter
>?
>? [TIME (regular index):], SECONDS() - lnSeconds
>