fastes way to search an array?

[Mike Bonner]

Ah k, so it would be situational.  After reading back in the thread some, I
suspect the tests would be 2 different strings, so testing for both would
be necessary. I was just not grokking the double.  Probably just easier to
set up a single string and check for it twice.

Either way, it runs through 100k records amazingly fast. (using 6.6.2 right
now)

Good to have the reminder that -or- checks only progress till the first
hit, or failure to hit.

On Thu, Apr 23, 2015 at 4:48 PM, Jerry Jensen <jhj at jhj.com> wrote:

> Actually it may be a bit faster with the two tests if a lot of them match
> at the beginning. Testing at the beginning (begins with) is a lot faster
> than spinning through the entire thing (contains), and if the first clause
> of the OR is satisfied, it won’t execute the second clause. So, maybe.
>
> I probably wouldn’t write it with the two tests unless I was really in a
> hurry and proved it to be an advantage with typical test data.
>
> Jerry
>
> > On Apr 23, 2015, at 3:38 PM, Mike Bonner <bonnmike at gmail.com> wrote:
> >
> > Did some testing out of curiosity, and WOW this is fast.
> >
> >
> > repeat for each key tKey in tArray
> >  if tArray[tKey] begins with tSearchString or \
> >     tArray[tKey] contains tSearchString then
> >    put tKey & return after tResults
> >  end if
> > end repeat
> >
> > The only question I have is.. why search for the same thing twice?  If it
> > "contains" it also "begins with" so its a redundant check.  (making it
> > faster)  Am I missing something here?
> >
> > On Thu, Apr 23, 2015 at 4:01 PM, Geoff Canyon <gcanyon at gmail.com> wrote:
> >
> >> On Wed, Apr 22, 2015 at 6:22 PM, Peter Haworth <pete at lcsql.com> wrote:
> >>
> >>> Out of interest, I added a test which used combine and filter.  It took
> >>> around 3 times longer than the other two tests.
> >>>
> >>
> >> Yeah, I didn't expect this to be competitive except under specific
> >> circumstances -- if the filter command happens to be suited to the
> >> (relatively complex) search performed, for example. I didn't see 3x,
> more
> >> like 1.5x to 2x, but still, iterating is generally the way to go.
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>