#1649 Reuse query counters

[justinweng-instaclustr]

This PR stores the query counters in a HashMap and reuses them when processing messages instead of registering query counters in every transform. According to the benchmark report, query_counter_pre_used gains 14% improvement thanks to the faster transform.

query_counter_fresh becomes a bit slower but it's expected because the first transform runs create the counters and insert them into the hashmap.

Progress towards #1649

[codspeed-hq]

CodSpeed Performance Report

Merging #1671 will improve performances by 17.72%

_{Comparing justinweng-instaclustr:1649-reuse-query-counter (c0ba0a1) with main (b9329ae)}

Summary

⚡ 1 improvements
✅ 38 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	justinweng-instaclustr:1649-reuse-query-counter	Change
⚡	query_counter_pre_used	14 µs	11.9 µs	+17.72%

[rukai]

nice work!
lets land this.

I think that if we ever want to further improve performance here, the best way would be to make redis_query_name return a new enum named RedisCommandType and then have a to_str() method on that enum.
That way we can make this work completely with &'static str and other usages of redis_query_name across the codebase would also be able to avoid the allocation.
But again, I think we've hit the sweetspot of how much time to spend on this problem since this will resolve the performance impacts that are being warned about in the new metrics release.

[justinweng-instaclustr]

nice work! lets land this.

I think that if we ever want to further improve performance here, the best way would be to make redis_query_name return a new enum named RedisCommandType and then have a to_str() method on that enum. That way we can make this work completely with &'static str and other usages of redis_query_name across the codebase would also be able to avoid the allocation. But again, I think we've hit the sweetspot of how much time to spend on this problem since this will resolve the performance impacts that are being warned about in the new metrics release.

Yeah sounds good. We can probably change redis_query_name to improve performance opportunistically in the future. Do we want to raise an issue for it just for tracking purpose?

[rukai]

I think just leave it, better in general to let performance work be driven by observed issues in the system rather then guessing which parts of the system are going to end up as the bottleneck.
I consider this work an exception since we had a warning pointing out a potential issue, better to resolve it than just ignore it.