BurntSushi commented on code in PR #6643:
URL: https://github.com/apache/opendal/pull/6643#discussion_r2419892540
##########
core/src/lib.rs:
##########
@@ -181,8 +181,8 @@ mod tests {
#[test]
fn assert_size() {
assert_eq!(16, size_of::<Operator>());
- assert_eq!(320, size_of::<Entry>());
- assert_eq!(296, size_of::<Metadata>());
+ assert_eq!(360, size_of::<Entry>());
+ assert_eq!(336, size_of::<Metadata>());
Review Comment:
A `Timestamp` and a `SignedDuration` should both be precisely as big as a
`std::time::Duration`. That is, an `(i64, i32)`.
In _debug_ builds, a `Timestamp` is bigger because of its use of ranged
integers internally that have extra data attached for detecting bugs at
runtime. But none of that is present in release builds. So if your tests are
running in debug mode (which I presume they are), then you'll see bigger sizes
than you actually get in release builds.
For example, consider this program:
```rust
fn main() {
dbg!(size_of::<jiff::Timestamp>());
dbg!(size_of::<chrono::DateTime<chrono::Utc>>());
}
```
And now their outputs in debug vs release:
```
$ cargo r -q
[main.rs:2:5] size_of::<jiff::Timestamp>() = 40
[main.rs:3:5] size_of::<chrono::DateTime<chrono::Utc>>() = 12
$ cargo r -rq
[main.rs:2:5] size_of::<jiff::Timestamp>() = 16
[main.rs:3:5] size_of::<chrono::DateTime<chrono::Utc>>() = 12
```
Chrono's type is a little more compact because a `DateTime<Utc>` isn't
actually a timestamp internally. In fact, Chrono doesn't have a pure timestamp
type. Internally, a `DateTime<Utc>` is a `NaiveDateTime` with a time zone
offset. Since `Utc` is zero sized, a `DateTime<Utc>` is just the size of a
`NaiveDateTime`. Jiff's analogous type is the same size:
```
$ cargo r -rq
[main.rs:4:5] size_of::<jiff::civil::DateTime>() = 12
[main.rs:5:5] size_of::<chrono::NaiveDateTime>() = 12
```
So if Jiff used the same representation as Chrono, then we'd get the same
size.
Jiff does _not_ use this representation for a timestamp type though because
1) it's weird to represent an instant by just a civil datetime and 2) now any
time you interact with the timestamp in a way in which that requires the actual
Unix timestamp, Chrono has to do arithmetic to convert the `NaiveDateTime` to
an actual timestamp. In Jiff, it's just simple integer arithmetic. And for that
reason, doing simple arithmetic is quite a bit faster in Jiff. From the
`./bench` directory of the Jiff repository:
```
$ cargo bench -- 'timestamp/(add_|from_seconds).*' --save-baseline timestamp
$ critcmp timestamp -g '(timestamp/[^/]+/[^/]+/)'
group timestamp/chrono
timestamp/jiff timestamp/time
----- ----------------
-------------- --------------
timestamp/add_time_secs/duration/ 2.26 6.1±0.08ns ? ?/sec
1.00 2.7±0.02ns ? ?/sec 3.89 10.5±0.11ns ? ?/sec
timestamp/add_time_secs/span/
1.00 14.7±0.12ns ? ?/sec
timestamp/add_time_subsec/duration/ 1.85 6.1±0.05ns ? ?/sec
1.00 3.3±0.03ns ? ?/sec 3.22 10.6±0.12ns ? ?/sec
timestamp/add_time_subsec/span/
1.00 22.3±0.27ns ? ?/sec
timestamp/from_seconds/integer/ 12.05 4.7±0.04ns ? ?/sec
1.00 0.4±0.00ns ? ?/sec 11.92 4.6±0.04ns ? ?/sec
```
(The `time` crate uses a similar representation as `chrono`.)
These benchmarks are defined here:
https://github.com/BurntSushi/jiff/blob/877d90a5f60e1668575953256cbf307366d2ce57/bench/src/timestamp.rs#L23-L159
While a few nanoseconds might not seem like much, these are exactly the
kinds of operations you might do in a loop. So the difference can easily add up.
Basically, a `jiff::Timestamp` is like a souped-up version of
`std::time::SystemTime` (and they are the same size in memory).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@opendal.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
