Thanks, Bill - I appreciate your thoughts (general and specific).
> On Feb 16, 2017, at 3:59 PM, Bill Ricker <bill.n1...@gmail.com> wrote:
>
> (a) if performance isn't really important, do which ever is easier to
> read and get right ( = unit-test).
> When you're bug fixing 6-24 months from now future-you will be happier
> and thank current-you.
> The 1st general rule is to defer optimization until proven it's needed.
> [See: Jon Bentley, [more] Programming Pearls]
>
Yes, I’m currently grateful to my four-years-ago self for all the comments in
the code as I’m updating / optimizing it. I am indeed facing a likely jump in
the volume of events to process (and users have to wait through processing time
since it’s part of an interactive web application), so I’m looking for possible
performance gains (without, as you say, losing the ability to understand what
the code is doing in the future).
One advantage of coming back to the code after a hiatus is that I can look at
it with fresh eyes. And after I sent this inquiry, I realized that both of the
approaches I was comparing are more complicated than they need to be - I can
calculate the angle of the Sun above (or below) the horizon at the desired time
and location, and that tells me whether it’s day or night. That was one of
those “well, duh” moments. That’s both faster to calculate and simpler to
understand in the code than either of my two previous ideas, so the relative
performance of the latter two is moot.
> (b) if performance matters because you have large volumes of events
> (compared to time waiting for them to process) , factor into a
> function and implement it two ways
> sub is_night_next { ... }
> sub is_night_span { ... }
> and use Benchmark qw(:all); benchmarking to compare the two:
> http://perldoc.perl.org/Benchmark.html
> http://perltricks.com/article/40/2013/9/29/How-to-benchmark-Perl-code-for-speed/
Thanks for the pointers here - will certainly try this to test the new code vs.
the old (with the same tests).
> At least this doesn't have an edge-case at DST ... and sunset at
> Swarthmore should be either before (DEC 31) or after (JUN 30) the UTC
> leap second, iirc. But there must be some lat-lon's where the leap
> second is perilously close to sunset (or sunrise in East longitude),
> something to consider if your code covers multiple lat-lon's.
Thanks for pointing out possible edge cases. This code does cover
(potentially) anywhere on Earth - it’s for letting my collaborators in a
network of telescopes determine what’s observable on a given night - but
one-second differences won’t be an issue in that determination; the choice of
different atmospheric refraction models make more difference than that in
setting the apparent position of the sun near sunset anyway, as do judgment
calls about what is “dark enough” to observe something.
Thanks again - I really appreciate the help.
Eric
