[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-datetime
Subject:    Re: Relative speed of DateTime::SpanSet->contains vs. DateTime::Set->next
From:       "Eric L. N. Jensen" <ejensen1 () swarthmore ! edu>
Date:       2017-02-17 15:33:02
Message-ID: 68E4DF4A-FCFF-4822-A5BC-ABBF30B05225 () swarthmore ! edu
[Download RAW message or body]

Thanks, Bill - I appreciate your thoughts (general and specific). 

> On Feb 16, 2017, at 3:59 PM, Bill Ricker <bill.n1vux@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


[prev in list] [next in list] [prev in thread] [next in thread]