Skip to content

WIP: Gas: 007 typechecker costs

Ilias Garnier requested to merge igarnier@tc-gas-007 into proto-proposal

We benchmarked and modelled the following points:

  • parsing costs for code, data, type
  • unparsing costs for code, data, type This includes all base types encodings, in readable and optimized format.

Core loops were benchmarked independently: merge_types, parse_instr, etc.

For data and code (parsing and unparsing) we generated random well-formed terms and fitted two models:

  • execution time as a function of term size (in number of nodes)
  • execution time as a function of consumed gas For types (parsing and unparsing) as well as merge_ypes, we generated random well-formed terms and fitted execution time as a function of term size. The type samplers are a bit stupid but the code being benched is very regular and the fit looks good enough.

The results are here:

Benchmarks for encodings can be found here. Most encodings are constant time. Readable encodings are quite costly, and the BLS from_bytes functions as well.

What this MR does

We update the costs of core loops according to the models described above. For typechecking and unparsing, there are also costs assigned to encoding/decoding at the leaves (ints, timestamp, etc), except for simple cases which are free (which are typically no-ops or small allocs).

Unclear points

The functions related to extracting lazy_storage updates were not benched. We assigned a cost which seems reasonable, looking at what the function does.

Still missing in this MR

  • updated micheline <-> bytes cost (we're going to use costs corresponding to the optimized Micheline encoding implementation by @klakplok; this implementation HAS to be merged in a release before 007 activates)
  • python test updates
Edited by Ilias Garnier

Merge request reports