Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
Creating 768GiB worth of pages (192M bits) takes 2.9ms: ``` test bitvec_from_elem_false/bits:256GiB/ops:1 ... bench: 144149 ns/iter (+/- 1961) test bitvec_from_elem_false/bits:512GiB/ops:1 ... bench: 1336148 ns/iter (+/- 50658) test bitvec_from_elem_false/bits:768GiB/ops:1 ... bench: 2917326 ns/iter (+/- 22253) ``` There is a significant performance improvement for 1TiB worth of pages (256M bits or 32MiB): ``` test bitvec_from_elem_false/bits:1008GiB/ops:1 ... bench: 4069684 ns/iter (+/- 17428) test bitvec_from_elem_false/bits:1TiB/ops:1 ... bench: 11312 ns/iter (+/- 53) test bitvec_from_elem_false/bits:2TiB/ops:1 ... bench: 12974 ns/iter (+/- 209) ``` The standard vector behaves similarly, so it's likely the underlying memory allocator optimizations: ``` test vec_from_elem_0/bits:768GiB/ops:1 ... bench: 2709736 ns/iter (+/- 27170) test vec_from_elem_0/bits:1008GiB/ops:1 ... bench: 3843070 ns/iter (+/- 111132) test vec_from_elem_0/bits:1TiB/ops:1 ... bench: 11379 ns/iter (+/- 564) test vec_from_elem_0/bits:2TiB/ops:1 ... bench: 12687 ns/iter (+/- 110) ``` Growing 768GiB worth of pages (192M bits) takes 2.6ms: ``` test bitvec_grow_false/bits:256GiB/ops:1 ... bench: 186167 ns/iter (+/- 2079) test bitvec_grow_false/bits:512GiB/ops:1 ... bench: 1169816 ns/iter (+/- 20458) test bitvec_grow_false/bits:768GiB/ops:1 ... bench: 2617347 ns/iter (+/- 22551) ``` There is a significant performance degradation for 1TiB worth of pages (256M bits or 32MiB). The root cause is likely the underlying memory allocator behavior and the fact that `BitVec::grow` initializes all the data. ``` test bitvec_grow_false/bits:1008GiB/ops:1 ... bench: 3568375 ns/iter (+/- 54736) test bitvec_grow_false/bits:1TiB/ops:1 ... bench: 23986994 ns/iter (+/- 463857) test bitvec_grow_false/bits:2TiB/ops:1 ... bench: 51976114 ns/iter (+/- 1330421) ``` The benchmark also confirms that allocating non-initialized memory (`bitvec_with_capacity` or `bitvec_reserve`) always takes a constant time: ``` test bitvec_with_capacity/bits:1TiB/ops:1 ... bench: 11705 ns/iter (+/- 246) test bitvec_with_capacity/bits:2TiB/ops:1 ... bench: 12682 ns/iter (+/- 48) test bitvec_reserve/bits:1TiB/ops:1 ... bench: 11379 ns/iter (+/- 84) test bitvec_reserve/bits:2TiB/ops:1 ... bench: 13149 ns/iter (+/- 112) ``` The benchmark shows that the canister scheduling overhead should be a function of state size. Also, for large memory allocations, `BitVec` itself should be optimized.
- Loading branch information