Given we've optimized the addReplyDouble API in # and after doing a quick benchamrk as follows:

memtier_benchmark -c 10 -t 2 --pipeline 10 --test-time 60 --command "GEODIST key element1 element2" --hide-histogram

We can see that the majority of the CPU cycles within GEODIST are for snprintf. out the 30% cpu-cycles of GEODIST, 20% are for snprintf.

Therefore I suggest we standardize the distance reply which will not only benefit approximate elements distance computation but also reduce the overhead of double to string conversion of the distance between points in the reply.