perf: update BTreeMap v2 default page size from 500 bytes to 1024 bytes #123
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The page size used by the BTreeMap dictates how big the chunks are that are allocated. The smaller the page size, the more chunks that need to be allocated to store the same amount of data, and consequently the more reads and writes are required to load/save each node. On the other hand, a large page size also can incur additional memory overhead, so we need to be careful to not set it too high.
To explore this, I added a benchmark that stores 200 10MiB vectors in a BTreeMap. I tested different page sizes to explore its effect on both memory and instructions.
When using a larger pages size, from 1KiB to 20MiB, this is the best increase in performance I had seen:
(relative performance is measured against the base line of
page_size = 500
)And I tried a page size of 1024:
As we can see, we captured nearly half of the performance improvement without increasing the page size too much, which seems to strike a good balance and it makes sense to have it as a default value.