Robert Brenstein wrote:
And that is what surprised me -- that no tinkering with arrays, or
matchtext, or anything else is faster than the most straightforward
Revolution syntax. I was thinking this would take a long time, but in
fact it is the fastest way to do it (that I've seen so far, anyway.)
We've mentioned this on the list before, but I guess I need to be hit
on the head with the facts occasionally, just to remind me how good
we've got it.
Surprise. Rev wins out again.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
I think that the time needed to prepare the text for searching should be
included since it is a required step and for large files can use enough
ticks to alter the results. Best would be to see both the total time and
search-only time.
If the processing had to be re-done for each file, then I included it in
the timing. But there were a few scripts where a one-time variable had
to be set up before any files were processed. I didn't think this was
important; it was almost always only one line of script and it only
happened once. I suppose it added a millisecond or two to the total.
I also didn't consider text preparation in my tests, because the text
I'll be reading in won't need any cleanup, and the words I'll be looking
for are stripped of punctuation before being passed to the scan. For
general use, you're probably right that we should include that.
I don't have time to redo all the tests (it took a while) but anyone who
wants to could grab the scripts off the list and see what they get. It's
always good to get more info, and I'm sure my results aren't definitive.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
