A B-Tree instead makes each node contain B-1 to 2B-1 elements in a contiguous array. By doing this, we reduce the number of allocations by a factor of B, and improve cache efficiency in searches. However, this does mean that searches will have to do more comparisons on average. The precise number of comparisons depends on the node search strategy used. For optimal cache efficiency, one could search the nodes linearly. For optimal comparisons, one could search the node using binary search. As a compromise, one could also perform a linear search that initially only checks every ith element for some choice of i.
Currently, our implementation simply performs naive linear search. This provides excellent performance on small nodes of elements which are cheap to compare. However in the future we would like to further explore choosing the optimal search strategy based on the choice of B, and possibly other factors. Using linear search, searching for a random element is expected to take B * log(n) comparisons, which is generally worse than a BST. In practice, however, performance is excellent.
https://doc.rust-lang.org/std/collections/struct.BTreeMap.html
But honestly I doubt i hit the 2B-1 element limit. so i cannot understand it sucks so hard compared to a Vec.
I still find the 2nd section of the doc really concerning, isn't that the whole sense of a btreemap xddd A B-Tree instead makes each node contain B-1 to 2B-1 elements in a contiguous array. By doing this, we reduce the number of allocations by a factor of B, and improve cache efficiency in searches. However, this does mean that searches will have to do more comparisons on average. The precise number of comparisons depends on the node search strategy used. For optimal cache efficiency, one could search the nodes linearly. For optimal comparisons, one could search the node using binary search. As a compromise, one could also perform a linear search that initially only checks every ith element for some choice of i.
Currently, our implementation simply performs naive linear search. This provides excellent performance on small nodes of elements which are cheap to compare. However in the future we would like to further explore choosing the optimal search strategy based on the choice of B, and possibly other factors. Using linear search, searching for a random element is expected to take B * log(n) comparisons, which is generally worse than a BST. In practice, however, performance is excellent.
https://doc.rust-lang.org/std/collections/struct.BTreeMap.html
But honestly I doubt i hit the 2B-1 element limit. so i cannot understand it sucks so hard compared to a Vec.
I still find the 2nd section of the doc really concerning, isn't that the whole sense of a btreemap xddd 
8255 t/s
that is defs enough to not destroy FPS too much 
1
1
all hard workers here
1
1
1
1
1
1
ma players .cpp for years just now noticed that it's map layers .cpp 
ma players .cpp for years just now noticed that it's map layers .cpp map players .cpp
1
1
Actually websockets are out for cool kids
if the sending to the server is unstable that can be seen in the ping