Multiple arguments with the filter command

[Jim Ault]

On 10/25/06 12:54 PM, "Mark Powell" <mark_powell at symantec.com> wrote:

> Thanks to both Jim and Marielle for their awesome feedback.  Instead of
> asking specific questions about the details of your feedback, I want to
> ask a general performance question.  The filter does work within a
> repeat loop like this:
Run this by creating a new mainstack, pasting the following into the stack
script, click apply, then doubleclick the card...
------- start copy ----------
on mouseDoubleUp
  repeat for 50000
    get " C:/The World/Asia/!?!"&the ticks &"prologue.ps!/1026/1115309596"
    put it & cr after vContainer
  end repeat
  put the ticks into startTicks
  put "9prolo, 8prolo" into vInputStrings  --about 10% will now be hits
  
  repeat for each item thisItem in vInputStrings
    get vContainer 
    filter it with ("*!*!*" & thisItem & "*!*") --note correction I made
    put cr & it after vNewContainer
  end repeat
   
  get the number of lines in vNewContainer
  put "The processing time to get "& it \
      &" lines was ..." & cr & ((the ticks - startTicks)/60) & \
      " seconds"
end mouseDoubleUp
------ end copy--------------------------
My answer in the IDE >>  The processing time to get 5042 lines was ...
0.416667 seconds

The reason I use ticks is to get fractional seconds.

> But given that vInputStrings could be very large, my concern is that the
> getting and putting involved would be dangerously memory- or
> processor-intensive.  What are the risks you have seen with the brute
> force approach like the one above?
Note:  downside to your loop is that you will get duplicate lines in your
listing if thisItem occurs on the same line as a previous thisItem.

Depending on speed tests, you can avoid duplicate result lines by:
if it is not among the lines of vNewContainer then
  put cr & it after vNewContainer
end if

For simpler filter commands, Rev is extremely fast.

For regEx and more complex filter commands, fast.

For complex regEx, slower, but usually more than adequate for user
interaction searches.  This may be too slow for continually updating the
result-field-listing while the user types each character.

You might want to publish the hits as they are found by:
    put it & cr before fld searchResults

Perhaps allow a user to halt the search once they see the results coming
along and need to revise something... quite often the case.

set the hilite of button userStop to false
repeat
    put it & cr before fld searchResults
    wait 20 milliseconds with messages
    if the hilite of button userStop is true then exit to top
end repeat


Jim Ault
Las Vegas