Faster timestamp parsing (~70-90% faster)#3801
Conversation
10b560e to
2652a5d
Compare
e767860 to
78bfa14
Compare
|
Impressive results! |
alamb
left a comment
There was a problem hiding this comment.
I went through the code carefully, it looks good (and very clever!) to me, nicely done @tustvold
Prior to merging this, I think it needs it needs significantly more test coverage (especially negative cases) -- previously we were relying on the chrono parser to be well tested and so don't have exhaustive tests. However, with our own parser I think we also need to add our own coverage. Maybe we can crib (borrow?) from the chrono test cases?
I agree with @jhorstmann that the reported results are very nice 🚀
| 3 => [bytes[1], bytes[2], b'0', b'0'], | ||
| _ => return None, | ||
| }; | ||
| values.iter_mut().for_each(|x| *x = x.wrapping_sub(b'0')); |
There was a problem hiding this comment.
this converts the ascii to the numeric representation, right? I am thinking that the use of wrapping sub ensures that any values like (20) that is lower than '0' will not pass this check, is that correct?
There was a problem hiding this comment.
Wrapping sub will just underflow harmlessly for such values, which will then fail on the check for < 9
|
I've added some more tests, PTAL, including the chrono test cases I could find... They aren't actually all that extensive... - https://github.com/chronotope/chrono/blob/main/src/format/parse.rs#L932 |
|
Benchmark runs are scheduled for baseline = de9f826 and contender = cdb042e. cdb042e is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
Which issue does this PR close?
Closes #.
Rationale for this change
What changes are included in this PR?
Are there any user-facing changes?