addReplyHumanLongDouble has a large overhead/weight on GEOPOS command performance #11565
Description
Profiling GEOPOS command we see that addReplyHumanLongDouble takes 62.36% of the total CPU cycles of the process:
Samples: 29K of event 'cycles', Event count (approx.): 109040523666
Children Self Command Shared Object Symbol
- 62.36% 0.53% redis-server redis-server [.] addReplyHumanLongDouble ◆
- 61.83% addReplyHumanLongDouble ▒
- 59.53% createStringObjectFromLongDouble ▒
- 57.06% ld2string ▒
- 55.61% snprintf (inlined) ▒
+ 55.51% ___snprintf_chk (inlined) ▒
+ 1.76% createStringObject (inlined) ▒
+ 2.26% addReplyBulk (inlined) ▒
+ 0.51% _start
In the past we've optimized addReplyDouble in #10587 .
Wanted to open this issue and discuss with @itamarhaber / @oranagra why we're using long double input for 2 double:
typedef struct geoPoint {
double longitude;
double latitude;
double dist;
double score;
char *member;
} geoPoint;
@itamarhaber I wanted to double check with you given the last change made on that geopos line was 7 years ago and exacly changing for double to long double reply "Eliminates engineers near the equator & prime meridian" :
Do you remember exactly why we need the long double? Or can we move to a double reply?
To reproduce:
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
memtier_benchmark --pipeline 10 --test-time 60 --command "GEOPOS key 1 2" --hide-histogram
Metadata
Metadata
Assignees
Labels
No labels