[go: up one dir, main page]

Proto: Allow key-value traversal for indexed carbonated storage

Context

Modules produced by Storage_functors.Make_indexed_carbonated_data_storage currently contains a function:

(* Old version *)
val list_values :
  ?offset:int ->
  ?length:int ->
  t ->
  (Raw_context.t * value list) tzresult Lwt.t

It can be used for collecting a list of values but not the keys.

This MR extends the function so that it also returns a list of key-value pairs:

(* New version *)
val list_key_values :
  ?offset:int ->
  ?length:int ->
  t ->
  (Raw_context.t * (key * value) list) tzresult Lwt.t

Since the module signature Non_iterable_indexed_carbonated_data_storage_with_values does contain the list_key_values function, it's renamed to Indexed_carbonated_data_storage.

The motivation is to use this function for testing purposes.

Manually testing the MR

No manual tests required. There are additional unit tests of this function which are run by:

>  dune exec ./src/proto_alpha/lib_protocol/test/unit/main.exe -- test Alpha_context

Benchmark

This MR introduces a step cost to consume gas in each step of the fold operation for list_key_values. For this purpose there's a benchmark module Storage_benchmark. Here's a script for inferring the list_key_values_step cost value:

BENCHMARK="List_key_values_alpha"
MODEL="list_key_values_step"

BENCH_NUM=500
NSAMPLES=100


SEED=1234
WORKLOAD_FILE="${BENCHMARK}.workload"
SOL_FILE="${BENCHMARK}.sol"

# Run benchmark
./tezos-snoop benchmark \
    "${BENCHMARK}" \
    and save to "${BENCHMARK}.workload" \
    --bench-num "${BENCH_NUM}" \
    --nsamples "${NSAMPLES}" \
    --seed "${SEED}"

# Infer parameters
./tezos-snoop \
    infer parameters for model "${MODEL}" \
    on data "${WORKLOAD_FILE}" using lasso --lasso-positive \
    --save-solution "${SOL_FILE}" \
    --plot

# Generate code
./tezos-snoop generate code using solution "${SOL_FILE}" and model "${BENCHMARK}"

image

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, the Development Version section of CHANGES.md for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR
Edited by Joel Bjornson

Merge request reports

Loading