Hi, 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"[1] (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[2] 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? [1] http://java.dzone.com/articles/joshua-bloch-performance (follow link) [2] effective Java, ed.2, item 30, Use enums instead of int constants Best regards, Thomas Koch, http://www.koch.ro
