Hi Richard,
You are right, I made an error writing tList instead of tLine (then
we gain about 25/30%).
But unfortunately it's not enough to say that a method or another is
always the better one.
That would be good news...
Le 12 juil. 05 à 23:10, Richard Gaskin a écrit :
Eric Chatonet wrote:
Hi Richard,
I think the speed depends on the filter complexity.
For instance:
on mouseUp
repeat 100000
if random (2) = 1 then put "zaz" & cr after tList
else put "zbz" & cr after tList
end repeat
-----
put the milliseconds into tStart1
filter tList with "*a*"
put the milliseconds - tStart1 into tResult1
-----
put the milliseconds into tStart2
repeat for each line tLine in tList
if "a" is in tList then put tLine & cr after tNewList
end repeat
delete char -1 of tNewList
put the milliseconds - tStart2 into tResult2
-----
put "Filter: " && tResult1 & cr &"Repeat:" && tResult2
end mouseUp
Results -
Filter: 41
Repeat: 117
To get cleaner results I think the second test's "is in tList"
should be "is in tLine", which also cuts execution time down
dramatically.
But the central point remains: with a small number of criteria the
filter command does a fine job compared to repeat loops, but for
complex criteria (in my app it's rare that we'll ever have fewer
than three distinct comparisons) "repeat for each" does well.
Another advantage of "repeat for each" is that it allows "or" in
additon to "and", which would require multiple passes with
"filter", and makes it easy to structure comparisons using
parentheses to control the order of precedence.
For the moment I'm sticking with the repeat loop for the situation
I'm currently using it in, but it's good to know that filter is
quick for simple searches.
_______________________________________________
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
