surprising filter benchmarks

[Eric Chatonet]

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.
>