CommandRegistry performance improvement

[BorysTheDev]

motivation:

1. all commands are predefined so the compiler can create a more efficient hash table in compile time
2. commands are not equal. We can split all commands into 2 types performance-oriented (set / get / find / calculate) and service commands (info / cluster / replica)

The way for improvement:

1. if-else construction for predefined strings can be easily transformed by a compiler into a hash table by string size and make comparisons as integers. Such an approach shows performance several times better than any runtime HashMap.
2. performance-oriented commands should be checked before service commands. In this case, the cache will be utilized more efficiently.

@romange I've read about this approach some time ago and unfortunately haven't found that article now

[kostasrim]

Two questions!

1. Why would we care about the performance of CommandRegistry? Have we ever noticed/seen that command lookup in the registry is a considerable bottleneck ? My two cents is that it is not. I see way more low hanging fruits that come from the design. For example proactor dispatch and multi hop operations, replying on single key commands on the dispatched proactor instead of doing the "hop" etc and I would expect that that there are more interesting optimizations there than the commend registry.

2. What do you mean by:

if-else construction for predefined strings can be easily transformed by a compiler into a hash table by string size and make comparisons as integers

Commands are executed at runtime, so the compiler knows nothing about transforming that string into an integer? Can you plz elaborate?

[BorysTheDev]

1. when I measured it was near 1% for CommandRegistry lookup. I agree that it's not critical but like an option.
2. if you know the size of the string the string is just copied into the register and the whole string compares at once like an integer.