pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-12 21:41:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Make election benchmarks more *memory-aware* (#9286)

Browse Source 
* Make benchmarks a bit better with mem

* Make election benchmarks more *memory-aware*

* Fix a few errors

* cargo run --release --features=runtime-benchmarks --manifest-path=bin/node/cli/Cargo.toml -- benchmark --chain=dev --steps=50 --repeat=20 --pallet=pallet_election_provider_multi_phase --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --output=./frame/election-provider-multi-phase/src/weights.rs --template=./.maintain/frame-weight-template.hbs

* Manually fix the weights

* Update lock file

* remove dupe

* Fix tests

* cargo update pwasm

Co-authored-by: Parity Bot <admin@parity.io>
This commit is contained in:
Kian Paimani
2021-07-09 21:55:31 +02:00
committed by GitHub
parent 9fc86cb55f
commit 3850a43323
11 changed files with 356 additions and 148 deletions
Download Patch File Download Diff File Expand all files Collapse all files
substrate/client/allocator/src/freeing_bump.rs
+10 -9
View File
@@ -38,9 +38,9 @@
//! allocation size is capped, therefore the number of orders and thus the linked lists is as well
//! limited. Currently, the maximum size of an allocation is 32 MiB.
//!
//! When the allocator serves an allocation request it first checks the linked list for the respective
//! order. If it doesn't have any free chunks, the allocator requests memory from the bump allocator.
//! In any case the order is stored in the header of the allocation.
//! When the allocator serves an allocation request it first checks the linked list for the
//! respective order. If it doesn't have any free chunks, the allocator requests memory from the
//! bump allocator. In any case the order is stored in the header of the allocation.
//!
//! Upon deallocation we get the order of the allocation from its header and then add that
//! allocation to the linked list for the respective order.
@@ -59,12 +59,13 @@
//! allocator was consumed by the 32 MiB allocation, allocations of all sizes except 32 MiB will
//! fail.
//!
//! - Sizes of allocations are rounded up to the nearest order. That is, an allocation of 2,00001 MiB
//! will be put into the bucket of 4 MiB. Therefore, any allocation of size `(N, 2N]` will take
//! up to `2N`, thus assuming a uniform distribution of allocation sizes, the average amount in use
//! of a `2N` space on the heap will be `(3N + ε) / 2`. So average utilisation is going to be around
//! 75% (`(3N + ε) / 2 / 2N`) meaning that around 25% of the space in allocation will be wasted.
//! This is more pronounced (in terms of absolute heap amounts) with larger allocation sizes.
//! - Sizes of allocations are rounded up to the nearest order. That is, an allocation of 2,00001
//! MiB will be put into the bucket of 4 MiB. Therefore, any allocation of size `(N, 2N]` will
//! take up to `2N`, thus assuming a uniform distribution of allocation sizes, the average amount
//! in use of a `2N` space on the heap will be `(3N + ε) / 2`. So average utilization is going to
//! be around 75% (`(3N + ε) / 2 / 2N`) meaning that around 25% of the space in allocation will be
//! wasted. This is more pronounced (in terms of absolute heap amounts) with larger allocation
//! sizes.
use crate::Error;
use std::{mem, convert::{TryFrom, TryInto}, ops::{Range, Index, IndexMut}};