Igor, I have thought about approach what you are talking about. It need add new field named like "sortedNodes" with custom ordering, which will have the same items as "nodes" field, because "nodes" has being used with default ordering in other methods. It have this advantages:
1. Method "nextNode" will look simpler. 2. Method "nextNode" will work faster, because using of method TreeSet#higher() will be available. But that possibility had not been used in original code. And I don't why. But also have some disadvantages because new field "sortedNodes" will be strongly connected with "nodes": 1. It need copy-paste all code, which modifies "nodes" in 4 other methods. It will decrease maintainability. 2. Field "nodes" is being used with "copy-on-write" algorithm. So state of "nodes" and "sortedNodes" can be inconsistent. Maybe it's okay, in fact I just don't know. But any way in future it may become a problem. So my opinion is that "presorted" approach can work a little bit faster (number of nodes never can't be so big that O(log n) became more faster than O(n)), but code complexity will been increased, because it will add one logic connection inside the whole class "TcpDiscoveryNodesRing". Yakov, can you settle our argument? 2017-01-20 16:30 GMT+03:00 Игорь Г <fre...@gmail.com>: > Alexander, maybe you should use presorted collection in > TcpDiscoveryNodesRing.nextNode instead of iterating through unsorted one > every time? >
