Contains vs is in
Richard Gaskin
ambassador at fourthworld.com
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