Why would you chose this over a Van Emde Boas tree where indexing, insert, delete are O(log log) and prev/next are constant? https://en.wikipedia.org/wiki/Van_

Why would you chose this over a Van Emde Boas tree where indexing, insert, delete are O(log log) and prev/next are constant? https://en.wikipedia.org/wiki/Van_Emde_Boas_tree https://en.wikipedia.org/wiki/Van_Emde_Boas_tree (it basically trades a little more work on indexing for a little loser structure) I like the use of the DE queue, but having to keep all the sub vectors packed to ensure constant time lookup might not be completely needed if you are willing to keep a little more information around or have two candidate buckets. Not sure if would be a win or not though, since they your probably just better using a VeB tree. e.g., I don't think you always need to compress everything back to the front if you can make sure all the buckets are within 1 or each other, but you can hit cases where you have to look in two buckets which isn't that difficult since you how the high and low of each bucket at the head and tail of each DEQ. But then you would need to keep some local coloring info keep the buckets perfectly balanced, as everything should be.