Contains vs is in

Richard Gaskin ambassador at
Tue Jan 3 15:16:45 EST 2017

Thanks. I've been accused of over-obsessing about performance so often 
that it didn't occur to me my comment could be seen as erring the other 
way. :)

I've done scraping, but fortunately here the simplest syntax is also the 
more efficient.

And even in tasks requiring fewer than a million iterations, it's often 
helpful to adopt habits that favor performance.

I like to think of it as the opposite of technical debt, a sort of 
savings account from which you can later draw clock cycles for new 
features or more thorough error-checking as needed.

But on balance, for all the benchmarking I've done over the years I try 
to remain mindful of the ROI of such efforts.

Sometimes it's quite high and well worth it.  Other times, not so much.

Some optimizations come at a cost not only to initial development as 
various options are explored, but also to ongoing maintenance. 
Sometimes highly-optimized code is really hard to read, and harder to 
fix or extend.

With any quantification, percentages are only part of a complete 
breakfast.  I find it helpful to keep absolute values in mind as well.

  Richard Gaskin
  Fourth World Systems

hh wrote:

 > I think he means
 > 10% of 1/100 of 1,000,000 iterations of a nano-million-dollar are 1
 > dollar.
 >> Richard Gaskin wrote:
 >> ?
 >>> Mike Kerner wrote:
 >>> > says the guy who doesn't scrape.
 >>> >
 >>> > On Mon, Jan 2, 2017 at 6:14 PM, Richard Gaskin wrote:
 >>> >
 >>> >> hh wrote:
 >>> >>
 >>> >> > I wasn't aware of that, good to know, "is in"/"contains" is 10%
 >>> >> > faster than "offset() > 0".
 >>> >>
 >>> >> But as with many benchmarks, it's helpful to keep the absolute 
times in
 >>> >> mind.
 >>> >>
 >>> >> In my quickie test script I had to use 1,000,000 iterations just 
to get
 >>> >> any appreciable duration to test.
 >>> >>
 >>> >> 10% of a fraction is a nanosecond isn't much to lose sleep over.
 >>> >> :)

More information about the use-livecode mailing list