Optimize cursor movement and selection manipulation

[as-cii]

This pull request contains a few changes that will optimize selection manipulation and cursor movement. I'd recommend reviewing it on a per-commit basis:

• f1361e8 fixes a logic error that was using Anchor::offset as an offset into the fragment
• cc7ce29 caches anchor positions until the buffer is edited
• a829f24 wraps FragmentId's vector of identifiers into an Rc
• 29b886e uses statically-allocated values for FragmentId::{min, max}_value
• 2d6c1b7 caches the mapping between offsets and points until the buffer is edited

I have tested the above optimizations following these steps:

• Edit the buffer 10000 times
• Add 1000 selections
• Start profiling
• Move right
• Stop profiling

Before	After

Note how the time spent in TextEditor (i.e., the call to Editor::move_right) has been reduced by a 35x factor. Performance is similar when moving cursors left, up or down.

Next Steps

We think this is a good first improvement that will allow xray to stay well under the frame budget, even when the user is manipulating thousands of selections at the same time. We are currently focusing on other areas of the system and, therefore, we are thinking to put further improvements to this on hold until more architectural concerns have been sorted out.

In the future we may revisit some areas of this code to optimize it even further, for example:

• Accesses to the B+ tree can have more cache-locality. Right now, accessing nodes and fragment ids always requires to follow a pointer wrapped by an Arc. This reduces the chances of having the data we need ready to consume in the cache during a tree traversal. As such, it might be interesting to explore using different representations for Node and FragmentId so that they are more cache-friendly.
• Reuse the same cursor across different tree traversals. Cursors use a Vec to represent a stack of seen nodes during a traversal. While a single vector allocation is innocuous, doing one of them for each selection means we will repeatedly allocate a value on the heap and free it shortly afterward. By using the same (pool of) cursor(s) over and over again, we will minimize memory allocations, which we've learned to be very expensive on hot code paths like this. One implementation thought for this could be to instantiate a cursor during the initialization of a buffer, wrapping it in a Arc. Then, we could hand out clones of that Arc and, in order to use the cursor, callers will have to invoke make_mut on it. If the cursor is used by someone else, it will just be copied and only then we will pay for a heap allocation.
• Speed up FragmentId comparisons. When resolving the position of an anchor we may end up comparing many fragment identifiers. Right now the size of a fragment id isn't known at compile time, so the number of comparison operations is not constant. We can partially solve this by using a more cache-friendly representation like suggested above, but constant factors may still be relatively high. As such, another idea would be to explore using SIMD instructions to compare two arbitrary fragment ids. This StackOverflow thread gives some insights on how we could do that.
• Overall, minimize heap accesses and use the stack as much as possible.

/cc: @nathansobo

[nathansobo]

When visiting a given node in the tree, we currently have to follow all the child pointers in order to fetch their spatial summaries. We should store a copy of the spatial summary of each child in the node that points to those children, so that we don't need to follow the pointer to a child unless we know it contains our target leaf. Combined with your other suggestions, this seems like it will greatly increase the cache friendliness of tree searches. Once we do this, we should experiment with different maximum node sizes to see what works the best, although it probably depends on the size of the summary nodes for any given tree.

It's also worth noting that #24 is relevant to some of what you have described here.