-
-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Benchmark improvements #38
Comments
My philosophy on benchmarks is that they should have some kind of verification step that ensures they are arriving to the expected answer. I've been burned way too many times by benchmarks measuring something you don't expect because the result isn't checked.
There is one benchmark where this is intentional (
Oh nice catch! Yes, I'll fix this. |
There were a few benchmarks where I was doing `timestamp()` comparisons unnecessarily. It was probably a transcription error. There is one benchmark though where it is intentional. Also, we used the `well_known` ISO 8601 format for `time` when parsing civil datetimes. There is a significant speed-up that comes with it. It's a hair faster than Jiff now in my benchmarks. Fixes #38
Yeah, I was referring to the benchmarks where it wasn't the intent. I recognized that one was specifically for that. |
Some things that I noticed while looking through the benchmarks:
assert_eq!
on everything? Wouldn'tlet _ = black_box(foo);
be sufficient for the compiler?chrono
ortime
. The values can be compared directly, avoiding an unrelated computation.parse_civil_datetime
can use the well-known ISO 8601 format fortime
, which should be significantly faster. Otherwise it's using the same parsing mechanism as yourstrptime
test.The text was updated successfully, but these errors were encountered: