Automated performance analysis summary

This comment was automatically generated given there is performance data available.

Using platform named: amd64-aws-m6i.8xlarge to do the comparison.

In summary:

• Detected a total of 11 stable tests between versions.

Comparison between unstable and judeng:sdscatrepr.

Time Period from a month ago. (environment used: oss-standalone)

@judeng / @zuiderkwast / @artikell looking at the performance data there is no significant change on the benchmarks detected ( I'm extending the runs to include all 60 benchmarks ).
Don't you want to think of benchmarks that would detect this improvement ( and in consequence detect regressions in the future about any change ) before merging?

@filipecosta90 As @judeng wrote in the top comment (quoted) this is not in the hot path of redis, so it's unlikely to affect performance.

sdscatrepr is not the hot path in redis, but it helpful for some project with sds.c, so it is still worth optimizing its performance

Maybe it affects performance of redis-cli or some external tools which copy the sds library such as hiredis... @judeng anything in particular you're using this for?

Anyway, I think this change is also a simplification of the code, so it can be worth merging anyway.

sdscarepr does not seem to be a hot path. I found that when there is a monitor, the replicationFeedMonitors will use the sdscarepr method. Maybe we can test it？

i use redis-benchmark --threads 2 -P 10 -r 100 -n 10000000 getset __rand_int__ __rand_int__ to test. The test results are as follows

unstable（no monitor）

Summary:
  throughput summary: 264669.28 requests per second
  latency summary (msec):
          avg       min       p50       p95       p99       max
        1.663     0.304     1.623     2.487     3.383    45.855

unstable（1monitor）

Summary:
  throughput summary: 78633.66 requests per second
  latency summary (msec):
          avg       min       p50       p95       p99       max
        5.917     0.312     4.815    11.711    31.775   171.391

judeng:sdscatrepr（no monitor）

Summary:
  throughput summary: 255761.02 requests per second
  latency summary (msec):
          avg       min       p50       p95       p99       max
        1.710     0.320     1.631     2.727     3.759    36.415

judeng:sdscatrepr（1 monitor）

Summary:
  throughput summary: 106142.47 requests per second
  latency summary (msec):
          avg       min       p50       p95       p99       max
        4.347     0.328     3.695     7.783    18.031   107.711

roughly 34% improvement。

@artikell Thanks for your test, the optimization of monitor was a surprise to me :-)

@filipecosta90 Thank you for the benchmark results you shared, I did not perform benchmark tests on redis, but only pressure tested the function in my project, which showed a great performance improvement.
maybe we can add some independent performance test cases in sdsTest to cover the basic functions, WDYT？

@zuiderkwast I am trying to make a tool based sds to audit redis's requests