On 10/25/06 12:54 PM, "Mark Powell" <[EMAIL PROTECTED]> 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 _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution