Long execution times for `.between()`

[lenovouser]

It looks like the iteration is always starting at dtstart instead of the start value passed to .between(), which makes it take a lot longer in correlation to the dtstart value.

In the example you can see that it already starts getting slow fairly quickly. For 2001 it takes about 100ms, for 2012 already one second, and by 2030 you are at 2-3 seconds.

import { DateTime, Frequency, RRule, RRuleSet } from 'rrule-rust';

let start = DateTime.utc(2000, 1, 1, 0, 0, 0);
let until = start;

const set = new RRuleSet({
    dtstart: start,
    rrules: [new RRule({ frequency: Frequency.Minutely })],
    tzid: 'UTC',
});

for (let year = 2000; year < 3000; year++) {
    start = until;
    until = DateTime.fromObject({ ...start.toObject(), year });

    const now = Date.now();
    const dates = set.between(start, until, false);
    const elapsed = Date.now() - now;
    console.log(`found ${dates.length} dates in year ${year}, took ${elapsed}ms`);
}

[lsndr]

Yeah, that's true, the lib goes through all dates. Thanks for reporting. I'll try to refactor it soon. But I fear there won't be a good solution for this due to how rrule algorithm works under the hood.

I compared it to js based rrule package and found out that on 2015 it already takes 15788ms while rrule-rust takes 1300ms

[lsndr]

Btw, what is your use case? Can it be solved by iterating over the whole set once and picking only the needed dates?

const set = new RRuleSet(options);

for (const date of set) {
  if(!isDateInRange(date)) {
    continue;
  }

  // .. your logic
}

[lenovouser]

@lsndr yeah I already feared it might be an issue inside the rrule crate / algorithm. Would be really happy in case you found a solution though.

Regarding your suggestion, this is not really a solution for us as we get the next date after now, then schedule something in the future. After the scheduled task is run, we compute the next date after now & schedule again.

This can have a frequency of secondly, or yearly, depends on the end user. If secondly & the rule is "older", so it has a dtstart far in the past, then it would always iterate over every second since then just to get the next occurrence.

The reason for us not using another way of scheduling is because rrule's allow users to more granularly specify which seconds produce a date or which days are an occurrence & so forth. Also multiple rrules can be interleaved.