-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add data loading for chinese precomputed caches #4468
Add data loading for chinese precomputed caches #4468
Conversation
…e_info_for_iso helper instead
Benchmark results:
Relevant snippets:
It's always faster, but not as much faster as I might have hoped. The date/datetime tests are somewhat expected, since half of those fixtures are for uncached years. Convert is not. I'd like to investigate this as a followup. |
1000x faster?
|
oh. I just didn't look at the unit. Oops |
For date/datetime I may tweak the bench to also test "only in cached range" dates as a separate bench |
use icu_provider::prelude::*; | ||
|
||
const YEARS: i32 = 200; | ||
const ISO_START: i32 = 1900; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just made these numbers up, open to other suggestions. Data size is currently 600B each.
Previously when Andrew and I were designing it we were including the related ISO year which would have limited the range to around 200 but now this range can be arbitrarily extended to whatever we want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you make it 250 years then we're right in the middle of the range.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think pre-unix epoch is less important than the future, I'd even go as far as saying 1950-2150.
Is there no cycle in this data? Or is the period just very large?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, there's no cycle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I bumped it to 250. Also open to making it 200 and 1950, but I think prior dates are actually somewhat important especially when it comes to peoples' birthdays. Not that important though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well there has to be a cycle at some point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why there has to be? If you're suggesting that all sequences of elements from a bounded set are cyclic, that's certainly not the case, check out the digits of pi.
The functions involved are periodic but their periods are not rational multiples of one another. The system overall is quasiperiodic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Living people's birthdays is also my rule of thumb.
Still not happy with it being in the high 10s of ns, expected it to be a bit lower. But less of a big deal, still in range. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great that this works!
Did two passes, read some of the functions in detail, don't see anything wrong or that I would change.
use icu_provider::prelude::*; | ||
|
||
const YEARS: i32 = 200; | ||
const ISO_START: i32 = 1900; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think pre-unix epoch is less important than the future, I'd even go as far as saying 1950-2150.
Is there no cycle in this data? Or is the period just very large?
@@ -445,6 +445,15 @@ mod test { | |||
use super::*; | |||
use crate::types::MonthCode; | |||
use calendrical_calculations::rata_die::RataDie; | |||
/// Run a test twice, with two calendars | |||
fn do_twice( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mmh, for-loop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How? Why? I don't think a for loop is cleaner than this, and this lets us tweak how we do it.
Part of #3933
This ties everything together, datagenning cached data for a period of 200 years after the year 1900 (eventually can be made configurable).
With this PR, cached data can be considered done for Chinese and Dangi. Islamic and Hebrew still need to have this work done, though it will hopefully be simpler.
I may want to do followup work investigating bechmark performance (see comment below)
This PR can be reviewed commit by commit.