Merge.

.cargo/release-version

@@ -1 +1 @@
-v0.16.3
+v0.16.15

.circleci/config.yml

@@ -480,6 +480,16 @@ jobs:
           workspace_member: ledger
           cache_key: snarkvm-ledger-cache
 
+  ledger-with-rocksdb:
+    docker:
+      - image: cimg/rust:1.71.1
+    resource_class: 2xlarge
+    steps:
+      - run_serial:
+          flags: --features=rocks
+          workspace_member: ledger
+          cache_key: snarkvm-ledger-with-rocksdb-cache
+
   ledger-authority:
     docker:
       - image: cimg/rust:1.71.1
@@ -854,6 +864,8 @@ workflows:
       - curves
       - fields
       - ledger
+# TODO (howardwu) - Implement `open_testing` on all storage, update to `CurrentConsensusStore::open_testing`, then re-enable.
+#      - ledger-with-rocksdb
       - ledger-authority
       - ledger-block
       - ledger-coinbase

.github/workflows/benchmarks.yml

@@ -60,7 +60,6 @@ jobs:
         run: |
           cd console/collections
           cargo bench --bench merkle_tree -- --output-format bencher | tee -a ../../output.txt
-          cargo bench --bench kary_merkle_tree -- --output-format bencher | tee -a ../../output.txt
           cd ../..
           
       - name: Benchmark curves

CONTRIBUTING.md

@@ -20,7 +20,7 @@ snarkVM is a big project, so (non-)adherence to best practices related to perfor
 ### Memory handling
 - if the final size is known, pre-allocate the collections (`Vec`, `HashMap` etc.) using `with_capacity` or `reserve` - this ensures that there are both fewer allocations (which involve system calls) and that the final allocated capacity is as close to the required size as possible
 - create the collections right before they are populated/used, as opposed to e.g. creating a few big ones at the beginning of a function and only using them later on; this reduces the amount of time they occupy memory
-- if an intermediate vector is avoidable, use an `Iterator` instead; most of the time this just amounts to omitting the call to `.collect()` if a single-pass iteraton follows afterwards, or returning an `impl Iterator<Item = T>` from a function when the caller only needs to iterate over that result once
+- if an intermediate vector is avoidable, use an `Iterator` instead; most of the time this just amounts to omitting the call to `.collect()` if a single-pass iteration follows afterwards, or returning an `impl Iterator<Item = T>` from a function when the caller only needs to iterate over that result once
 - when possible, fill/resize collections "in bulk" instead of pushing a single element in a loop; this is usually (but not always) detected by `clippy`, suggesting to create vectors containing a repeated value with `vec![x; N]` or extending them with `.resize(N, x)`
 - when a value is to eventually be consumed in a chain of function calls, pass it by value instead of by reference; this has the following benefits:
   * it makes the fact that the value is needed by value clear to the caller, who can then potentially reclaim it from the object afterwards if it is "heavy", limiting allocations