In the pursuit of a faster strptime implementation, two backing Rust crates were chosen due to their popularity in the ecosystem – chrono and time.
Both impementations are exposed under the following methods:
fastdatetime.strptime(based on time along with time-fmt)fastdatetime.chrono.strptime(based on chrono)
Initially, chrono seemed liked a drop-in replacement, however due to subtle differences of %f specifier the format argument needs to preprocessed to conform to the Python referece which incurs slight performance overhead as the format string needs to be scanned.
Furthermore, even without this shortcoming, the parsing was slower compared to time.
What's also interesting is that time doesn't support strptime compatible inferface out of the box – fortunatelly time-fmt does (in addition, some fixes and new functionality was upstreamed to the crate).
Oftentimes the date format is not known ahead of time, or it is not possible to infer it from a few samples. In Python, one would usually opt for using the dateutil package, which can deal with all sorts of edge cases and is very forgiving, however these guarantees come at a cost – in order for the results to not be ambiguous but accurate, the user can tweak a lot of options (is the day or year first, ...) and has to sacrifice performance.
Enter dtparse by Bradlee Speice, a rewrite of dateutil.parse in Rust. Going full circle, fastdatetime just exposes Python bindings to Bradlee's excellent crate. This yields ~15x faster parsing performance (657 vs 42 Kops/sec on M1 Pro).
TBD
TBD
-
chrono as an alternative implementation parse
strptimeformats (specifiers reference) -
pyo3 for Python bindings
-
maturin for building Python wheels
© 2022 Contributors of Project fastdatetime.
This project is licensed under either of
at your option.
The SPDX license identifier for this project is MIT OR Apache-2.0.