Store vtables sorted in Rust builder #6765
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
August 2, 2021 16:46
The previous implementation was slow if there were too many tables. Asymototically when inserting the n^th vtable: The old implementation took O(n) lookup steps and O(1) insertion. The new implementation is O(log n) lookup and O(n) insertion. This might be improved further by using a balanced btree. Benchmarking, create_many_tables is 7.5x faster (on my laptop): // Simple vector cache test create_many_tables ... bench: 728,875 ns/iter (+/- 12,279) = 44 MB/s // Sorted vector cache test create_many_tables ... bench: 97,843 ns/iter (+/- 4,430) = 334 MB/s
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 previous implementation was slow if there were too many tables.
It linearly searches a vector for vtable duplicates. The new implementation
binary searches a vector for duplicates.
Asymototically when inserting the n^th vtable: The old implementation
took O(n) lookup steps and O(1) insertion. The new implementation is
O(log n) lookup and O(n) insertion. This might be improved further by
using a balanced binary tree stored in a vector.
Note that std::collections do not work for us. This is because we store keys
into the flatbuffer's owned buffer. This buffer may move due to reallocation
so we cannot rely on references/pointers, instead we must pass the buffer
with each comparison, which does not fit the standard API.
Benchmarking, create_many_tables is 7.5x faster (on my laptop):
// Simple vector cache
test create_many_tables ... bench: 728,875 ns/iter (+/- 12,279) = 44 MB/s
// Sorted vector cache
test create_many_tables ... bench: 97,843 ns/iter (+/- 4,430) = 334 MB/s