Avoid double-loop and branching for leap years

[MichaelChirico]

Supersedes #429.

Actually, we can avoid the variable-length array issue altogether. The old implementation uses leap to:

1. Run a full nyear loop to populate whether each year is leap
2. Run a second loop to read from this array to count the number of days. It also has a branch in each iteration which will be pretty volatile since branch prediction will be wrong ~half the time.

It's better to just count the number of days directly in a single loop. This will be slightly more memory-efficient, and should be more computationally efficient too.

[MichaelChirico]

Locally I added a fast parameter to the routine and put the master code under !fast, this branch under fast to compare:

library(microbenchmark)
soy=xts:::startOfYear

# Comparing defaults: ~10% faster
microbenchmark(times=1e6, fast=soy(fast=TRUE), slow=soy(fast=FALSE))
# Unit: microseconds
#  expr   min    lq     mean median    uq      max neval
#  fast 2.411 4.142 5.498975  4.251 4.421 55194.07 1e+06
#  slow 2.571 4.621 5.851015  4.731 4.911 13580.37 1e+06

# Comparing huge edge case: ~40% faster
microbenchmark(times=1e4, fast=soy(from=0,to=1e4, fast=TRUE), slow=soy(from=0, to=1e4, fast=FALSE))
# Unit: microseconds
#  expr   min    lq     mean median     uq      max neval
#  fast 35.92 42.36 50.34491 43.301 44.471 12413.64 10000
#  slow 48.62 57.82 72.48831 59.040 60.631 12848.52 10000

This internal routine is only called once, here, so the default comparison is the fairest:

xts/R/index.R

Line 373 in ae39d2b

((startOfYear() * 86400 + (3 * 86400)) %/% 86400 %/% 7)[.indexyear(x) + 1]

[joshuaulrich]

Thanks for this and the prior PR! I agree that this one is better, mostly because it's simpler.

Also, I wouldn't worry about the 'fast' parameter. The routine is only used in one function to find the week of the year, and the improvement is only a handful of microseconds.

[MichaelChirico]

Also, I wouldn't worry about the 'fast' parameter.

Sorry, to clarify, I only did that to make the benchmark simpler, no plan to add it to the PR.

[joshuaulrich]

Oh, I misunderstood! Now I understand that your PR is ~40% faster than the current code. That's a nice added bonus to the simpler code!

[MichaelChirico]

I think 10% is a fairer comparison since the function is only ever called with defaults as of now :)

[joshuaulrich]

Thanks for your work on this!