The problem/use-case that the feature addresses
Putting it simply all use cases that heavily rely on string to floating-point conversion, (e.g. meaning take a string like "1.5" and return a 64-bit double-precision floating-point number like 1.5 ), could benefit from a performance boost by swapping strtod by the equivalent fast_double_parser, as measured by Daniel Lemire ( @lemire on GH ) on his blog https://lemire.me/blog/2020/03/10/fast-float-parsing-in-practice/ :
| parser |
MB/s |
| fast_double_parser (new) |
660 MB/s |
| abseil, from_chars |
330 MB/s |
| double_conversion |
250 MB/s |
| strtod |
70 MB/s |
The 99% cases performance improvement and correctness of 100%: Putting it simply, when we cannot use the Eisel-Lemire algorithm we fall back to the equivalent strtod, meaning this change is 100% compatible.
Real application use-case
We've applied the fast_double_parser to a Redis Module ( RedisTimeSeries ) by leveraging a C Wrapper for the C++ Eisel-Lemire ParseFloat algorithm, and noticed a bump in performance on our write workflows of ~=8% on the achievable ops/sec, as detailed here: RedisTimeSeries/RedisTimeSeries#683. For the redis use-case I believe we should not use C++ at all and rely upon solely on a C header-only library ( as described bellow ).
Description of the feature
Leverage a C Header only library ( based on the C++ one available here: https://github.com/lemire/fast_double_parser/blob/master/include/fast_double_parser.h )
Additional information
I would very much like to push this POC forward, meaning I volunteer to make available and test the C header-only lib and apply it to Redis and check the performance improvements :)
The problem/use-case that the feature addresses
Putting it simply all use cases that heavily rely on string to floating-point conversion, (e.g. meaning take a string like "1.5" and return a 64-bit double-precision floating-point number like 1.5 ), could benefit from a performance boost by swapping
strtodby the equivalentfast_double_parser, as measured by Daniel Lemire ( @lemire on GH ) on his blog https://lemire.me/blog/2020/03/10/fast-float-parsing-in-practice/ :The 99% cases performance improvement and correctness of 100%: Putting it simply, when we cannot use the Eisel-Lemire algorithm we fall back to the equivalent strtod, meaning this change is 100% compatible.
Real application use-case
We've applied the fast_double_parser to a Redis Module ( RedisTimeSeries ) by leveraging a C Wrapper for the C++ Eisel-Lemire ParseFloat algorithm, and noticed a bump in performance on our write workflows of ~=8% on the achievable ops/sec, as detailed here: RedisTimeSeries/RedisTimeSeries#683. For the redis use-case I believe we should not use C++ at all and rely upon solely on a C header-only library ( as described bellow ).
Description of the feature
Leverage a C Header only library ( based on the C++ one available here: https://github.com/lemire/fast_double_parser/blob/master/include/fast_double_parser.h )
Additional information
I would very much like to push this POC forward, meaning I volunteer to make available and test the C header-only lib and apply it to Redis and check the performance improvements :)