Changed externref_table to use geometric resizing, giving amortized constant time additions #2294
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.
Previously
__wbindgen_externref_table_grow
was called inalloc
adding a constant size each time.This results in taking Theta(N) time amortized to pass a single new
JsValue
to wasm, where N is number/size of existing items.Changes
This pull request resizes geometrically, giving amortized constant additions to the externref_table.
Specifically,
max(128, curr_len)
, so that we the larger of 128*usize, or the size of the current array.This results in a growth factor of 2, the same as Rust's
Vec
growth factorTesting:
It fixes #2291, where it took over 150 seconds to add 1.2 million
JsValues
's to a Vec on my PC with reference types enabled.Now, it takes only 0.7-0.9 seconds.
Pros
Reduces complexity from
Theta(N^2)
to passN
JsValue
s to wasm toTheta(N)
Cons
Slightly more memory required -- After resizing, the table will be half full.
I'm setting this as draft, since this is my first PR! :)
All tests passed for me. Tell me if I missed anything!