I've filled two issues, ZK-1199 and ZK-1231, suggesting that ZooDefs.OpCode
and the list of QuorumPackage types in Leader should be refactored to Enums
instead of long lists of final static ints.
Benjamin Reed raised his concerns in a comment to ZK-1199:
"-1 i don't think this is a valid issue. the op code evaluation is in time
critical code and we should be doing less type conversion rather than more. it
would be much better to write a utility class that converts from op code
integer to string."
Today I watched Joshua Bloch's talk "Performance Anxiety" (highly
recommended!). The takeaway of the talk is that you can't really predict the
performance impact of micro code nowadays in the presence of JITs, three level
of caches, speculative execution and what other tricks have been added in the
last decades. So nobody of us can really tell, whether the use of Enums
instead of integer constants will have a positive or negative performance
impact or none at all.
However it may be possible that the few cpu cycles necessary to map from
integer to an Enum and back again are neglectable compared to the time a
request spends on the network or waiting for the disc.
Wouldn't it therefor be the better approach to take Joshua Bloch's advise
and just use Enums? A better structured and comprehensable code on the other
hand is a better base for refactorings that could have real performance
benefits, like embracing immutability and reducing synchronizations.
May I ask for your opinions on this matter?
In case that you consider enums as being to slow, should I refactor the Enum
FastLeaderElection.ToSend.mType to static int constants?
 http://java.dzone.com/articles/joshua-bloch-performance (follow link)
 effective Java, ed.2, item 30, Use enums instead of int constants
Thomas Koch, http://www.koch.ro