Speedup GEODIST with fixedpoint_d2string as an optimized version of snprintf %.4f#11552
Conversation
oranagra
left a comment
There was a problem hiding this comment.
on a first glance, it looks scary, too much low level code to replace something simple.
however, reading the explanation of the decimal point shift i think it's neat.
maybe if we can move that function to utils.c and generalize it a bit, then i'd feel better.
i.e. int fixedpoint_d2string(char *buf, size_t len, double value, int fractional_digits)
then it'll be a generic optimized algorithm like our ull2string, and not some special geo hack that's going too deep.
oranagra
left a comment
There was a problem hiding this comment.
another (last) round of comments.
only now i actually reviewed the implementation code, and not just the general concept.
Co-authored-by: Oran Agra <[email protected]>
|
@oranagra followed the recommendations and updated the numbers on the PR description. |
…nprintf %.4f (#11552) GEODIST used snprintf("%.4f") for the reply using addReplyDoubleDistance, which was slow. This PR optimizes it without breaking compatibility by following the approach of ll2string with some changes to match the use case of distance and precision. I.e. we multiply it by 10000 format it as an integer, and then add a decimal point. This can achieve about 35% increase in the achievable ops/sec. Co-authored-by: Oran Agra <[email protected]> (cherry picked from commit 61c85a2)
…nprintf %.4f (redis#11552) GEODIST used snprintf("%.4f") for the reply using addReplyDoubleDistance, which was slow. This PR optimizes it without breaking compatibility by following the approach of ll2string with some changes to match the use case of distance and precision. I.e. we multiply it by 10000 format it as an integer, and then add a decimal point. This can achieve about 35% increase in the achievable ops/sec. Co-authored-by: Oran Agra <[email protected]>
…nprintf %.4f (redis#11552) GEODIST used snprintf("%.4f") for the reply using addReplyDoubleDistance, which was slow. This PR optimizes it without breaking compatibility by following the approach of ll2string with some changes to match the use case of distance and precision. I.e. we multiply it by 10000 format it as an integer, and then add a decimal point. This can achieve about 35% increase in the achievable ops/sec. Co-authored-by: Oran Agra <[email protected]>
…dis#11631) Fixes a regression introduced by redis#11552 in 7.0.6. it causes replies in the GEO commands to contain garbage when the result is a very small distance (less than 1) Includes test to confirm indeed with junk in buffer now we properly reply
GEODIST used snprintf("%.4f") for the reply using addReplyDoubleDistance, which was slow.
This PR optimizes it without breaking compatibility by following the approach of ll2string with some changes to match the use case of distance and precision.
I.e. we multiply it by 10000 format it as an integer, and then add a decimal point.
This can achieve about 35% increase in the achievable ops/sec.
Details
Out of the 36.44% geodistCommand CPU cycles we can pinpoint 26.02% to addReplyDoubleDistance:
To functionally test it:
To benchmark:
Use the following RDB with 60M datapoints on the GEO key. https://s3.us-east-2.amazonaws.com/redis.benchmarks.spec/datasets/geopoint/dump.rdb
unstable branch ( 155acef )
this PR (c7bb268)
Approximately 35% increase in the achievable ops/sec.