fluencelabs/aquavm
1
0
Fork 0
mirror of https://github.com/fluencelabs/aquavm synced 2025-03-16 04:50:49 +00:00
Code Issues Projects Releases Wiki Activity
aquavm/benches/PERFORMANCE.txt

1210 lines
58 KiB
Plaintext
Raw Normal View History

chore(bench): add bench results (#467) add bench results for current Marine
2023-02-14 09:59:49 +02:00
Machine 05b76e53f793eceba4cb1e947eecaedf581b236317d6c24d5fba40ce9350735f:
Platform: Linux-5.10.136-x86_64-AMD_Ryzen_9_5950X_16-Core_Processor-with-glibc2.36
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
Timestamp: 2023-02-14 07:53:57.703442+00:00
chore(bench): add bench results (#467) add bench results for current Marine
2023-02-14 09:59:49 +02:00
AquaVM version: 0.35.1
Benches:
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
big_values_data (7.05ms): Loading a trace with huge values
air::runner::execute_air: 7.05ms
farewell_step::outcome::from_success_result: 2.77ms
populate_outcome_from_contexts: 2.74ms
to_vec(call_results): 9.00µs
to_vec(data): 2.21ms
preparation_step::preparation::prepare: 4.21ms
air::preparation_step::preparation::make_exec_ctx: 12.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 4.14ms
air_parser::parser::air_parser::parse: 15.00µs
runner::execute: 6.00µs
dashboard (45.83ms): big dashboard test
air::runner::execute_air: 45.83ms
farewell_step::outcome::from_success_result: 224.00µs
populate_outcome_from_contexts: 200.00µs
chore(bench): add bench results (#467) add bench results for current Marine
2023-02-14 09:59:49 +02:00
to_vec(call_results): 13.00µs
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
to_vec(data): 102.00µs
preparation_step::preparation::prepare: 448.00µs
air::preparation_step::preparation::make_exec_ctx: 19.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 275.00µs
air_parser::parser::air_parser::parse: 95.00µs
runner::execute: 45.09ms
execute: 40.68ms
execute: 4.10ms
instructions::call::resolved_call::prepare_request_params: 337.00µs
instructions::call::resolved_call::serde_json::to_string(tetraplets): 14.00µs
resolver::resolve::resolve_ast_variable: 216.00µs
resolve_variable: 70.00µs
resolver::resolve::resolve_ast_variable: 572.00µs
resolve_variable: 184.00µs
new: 26.91ms
resolve_ast_scalar: 20.17ms
resolve_ast_variable: 12.53ms
resolve_variable: 4.08ms
long_data (2.05ms): Long data trace
air::runner::execute_air: 2.05ms
farewell_step::outcome::from_success_result: 597.00µs
populate_outcome_from_contexts: 573.00µs
to_vec(call_results): 9.00µs
to_vec(data): 300.00µs
preparation_step::preparation::prepare: 1.39ms
air::preparation_step::preparation::make_exec_ctx: 22.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 1.30ms
air_parser::parser::air_parser::parse: 14.00µs
runner::execute: 6.00µs
network_explore (3.52ms): 5 peers of network are discovered
air::runner::execute_air: 3.52ms
farewell_step::outcome::from_success_result: 100.00µs
populate_outcome_from_contexts: 79.00µs
to_vec(call_results): 8.00µs
chore(bench): add bench results (#467) add bench results for current Marine
2023-02-14 09:59:49 +02:00
to_vec(data): 25.00µs
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
preparation_step::preparation::prepare: 191.00µs
air::preparation_step::preparation::make_exec_ctx: 14.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 70.00µs
air_parser::parser::air_parser::parse: 52.00µs
runner::execute: 3.17ms
execute: 2.83ms
execute: 470.00µs
resolve_ast_variable: 189.00µs
resolve_variable: 61.00µs
new: 1.69ms
resolve_ast_scalar: 1.25ms
resolve_ast_variable: 780.00µs
resolve_variable: 258.00µs
parser_10000_100 (17.82ms): Running very long AIR script with lot of variables and assignments
air::runner::execute_air: 17.82ms
farewell_step::outcome::from_success_result: 77.00µs
populate_outcome_from_contexts: 58.00µs
to_vec(call_results): 8.00µs
to_vec(data): 14.00µs
preparation_step::preparation::prepare: 16.93ms
air::preparation_step::preparation::make_exec_ctx: 12.00µs
air_parser::parser::air_parser::parse: 16.87ms
runner::execute: 95.00µs
execute: 65.00µs
execute: 11.00µs
new: 13.00µs
chore(benches): update benchmark data to new format (#559) * feat(aquavm-air-cli): `run` fails if AquaVM fails Unless `run --no-fail` is provided. It will make benchmarks fail on errors, unless you provide `--no-fail` to specific benchmark. * Fix dashboard and network_explore benches * Convert benchmark data to new format * `performance_metering`: use dirs only Ordinary files like README.md are not considered to be a benchmark. * Update `benches/performance_metering/README.md` * Fix performance report Looks like performance reports was merged in wrong order: data is not sorted by machine ID. The sorting is needed for stable diffs. * Run benchmarks on Macbook Air M1
2023-04-11 02:27:32 +07:00
Machine 0dfa4f098d7a6ef0d77a7bbc028ccf65fd6dc8d37be8a466ab3933a1a4a8e113:
Platform: macOS-11.7.3-x86_64-i386-64bit
Timestamp: 2023-02-14 04:31:01.303450+00:00
AquaVM version: 0.35.1
Benches:
big_values_data (14.17ms): Loading a trace with huge values
air::runner::execute_air: 14.17ms
farewell_step::outcome::from_success_result: 6.08ms
populate_outcome_from_contexts: 6.00ms
to_vec(call_results): 17.00µs
to_vec(data): 4.95ms
preparation_step::preparation::prepare: 7.87ms
air::preparation_step::preparation::make_exec_ctx: 40.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 7.61ms
air_parser::parser::air_parser::parse: 66.00µs
runner::execute: 18.00µs
dashboard (89.32ms): big dashboard test
air::runner::execute_air: 89.32ms
farewell_step::outcome::from_success_result: 469.00µs
populate_outcome_from_contexts: 415.00µs
to_vec(call_results): 33.00µs
to_vec(data): 215.00µs
preparation_step::preparation::prepare: 1.06ms
air::preparation_step::preparation::make_exec_ctx: 56.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 589.00µs
air_parser::parser::air_parser::parse: 233.00µs
runner::execute: 87.58ms
execute: 78.38ms
execute: 7.91ms
instructions::call::resolved_call::prepare_request_params: 678.00µs
instructions::call::resolved_call::serde_json::to_string(tetraplets): 36.00µs
resolver::resolve::resolve_ast_variable: 416.00µs
resolve_variable: 131.00µs
resolver::resolve::resolve_ast_variable: 1.09ms
resolve_variable: 362.00µs
new: 50.99ms
resolve_ast_scalar: 37.72ms
resolve_ast_variable: 23.15ms
resolve_variable: 7.40ms
long_data (4.44ms): Long data trace
air::runner::execute_air: 4.44ms
farewell_step::outcome::from_success_result: 1.32ms
populate_outcome_from_contexts: 1.24ms
to_vec(call_results): 23.00µs
to_vec(data): 672.00µs
preparation_step::preparation::prepare: 2.88ms
air::preparation_step::preparation::make_exec_ctx: 64.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 2.59ms
air_parser::parser::air_parser::parse: 63.00µs
runner::execute: 22.00µs
network_explore (8.09ms): 5 peers of network are discovered
air::runner::execute_air: 8.09ms
farewell_step::outcome::from_success_result: 256.00µs
populate_outcome_from_contexts: 198.00µs
to_vec(call_results): 21.00µs
to_vec(data): 62.00µs
preparation_step::preparation::prepare: 661.00µs
air::preparation_step::preparation::make_exec_ctx: 60.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 244.00µs
air_parser::parser::air_parser::parse: 174.00µs
runner::execute: 6.94ms
execute: 6.12ms
execute: 1.02ms
resolve_ast_variable: 393.00µs
resolve_variable: 124.00µs
new: 3.57ms
resolve_ast_scalar: 2.61ms
resolve_ast_variable: 1.60ms
resolve_variable: 517.00µs
parser_10000_100 (32.25ms): Running very long AIR script with lot of variables and assignments
air::runner::execute_air: 32.25ms
farewell_step::outcome::from_success_result: 202.00µs
populate_outcome_from_contexts: 152.00µs
to_vec(call_results): 17.00µs
to_vec(data): 45.00µs
preparation_step::preparation::prepare: 29.95ms
air::preparation_step::preparation::make_exec_ctx: 49.00µs
air_parser::parser::air_parser::parse: 29.74ms
runner::execute: 264.00µs
execute: 169.00µs
execute: 29.00µs
new: 40.00µs
chore(bench): add bench results (#465) bench results
2023-02-13 15:57:13 +03:00
Machine 5fce753d17dde8b439ef04cdbce135789eb44646c753548ad79a37b88cf17f0a:
Platform: macOS-12.3.1-arm64-arm-64bit
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
Timestamp: 2023-02-13 16:59:20.507375+00:00
chore(bench): add bench results (#465) bench results
2023-02-13 15:57:13 +03:00
AquaVM version: 0.35.1
Benches:
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
big_values_data (31.97ms): Loading a trace with huge values
air::runner::execute_air: 31.97ms
farewell_step::outcome::from_success_result: 10.56ms
populate_outcome_from_contexts: 8.69ms
to_vec(call_results): 108.00µs
to_vec(data): 5.66ms
preparation_step::preparation::prepare: 17.47ms
air::preparation_step::preparation::make_exec_ctx: 1.40ms
air_interpreter_data::interpreter_data::serde_json::from_slice: 10.68ms
air_parser::parser::air_parser::parse: 1.86ms
runner::execute: 126.00µs
dashboard (103.60ms): big dashboard test
air::runner::execute_air: 103.60ms
farewell_step::outcome::from_success_result: 4.71ms
populate_outcome_from_contexts: 3.70ms
to_vec(call_results): 162.00µs
to_vec(data): 1.87ms
preparation_step::preparation::prepare: 16.17ms
air::preparation_step::preparation::make_exec_ctx: 1.61ms
air_interpreter_data::interpreter_data::serde_json::from_slice: 5.50ms
air_parser::parser::air_parser::parse: 6.11ms
runner::execute: 78.68ms
execute: 66.40ms
execute: 9.37ms
instructions::call::resolved_call::prepare_request_params: 1.43ms
instructions::call::resolved_call::serde_json::to_string(tetraplets): 398.00µs
resolver::resolve::resolve_ast_variable: 335.00µs
resolve_variable: 105.00µs
resolver::resolve::resolve_ast_variable: 946.00µs
resolve_variable: 277.00µs
new: 40.53ms
resolve_ast_scalar: 29.73ms
resolve_ast_variable: 18.24ms
resolve_variable: 5.84ms
long_data (24.35ms): Long data trace
air::runner::execute_air: 24.35ms
farewell_step::outcome::from_success_result: 6.79ms
populate_outcome_from_contexts: 5.07ms
to_vec(call_results): 108.00µs
to_vec(data): 2.23ms
preparation_step::preparation::prepare: 13.54ms
air::preparation_step::preparation::make_exec_ctx: 1.75ms
air_interpreter_data::interpreter_data::serde_json::from_slice: 6.77ms
air_parser::parser::air_parser::parse: 1.84ms
runner::execute: 130.00µs
network_explore (46.01ms): 5 peers of network are discovered
air::runner::execute_air: 46.01ms
farewell_step::outcome::from_success_result: 5.48ms
populate_outcome_from_contexts: 4.50ms
to_vec(call_results): 105.00µs
to_vec(data): 2.25ms
preparation_step::preparation::prepare: 18.74ms
air::preparation_step::preparation::make_exec_ctx: 1.98ms
air_interpreter_data::interpreter_data::serde_json::from_slice: 7.05ms
air_parser::parser::air_parser::parse: 6.74ms
runner::execute: 17.86ms
execute: 9.97ms
execute: 3.17ms
resolve_ast_variable: 339.00µs
resolve_variable: 94.00µs
new: 4.10ms
resolve_ast_scalar: 2.65ms
resolve_ast_variable: 1.67ms
resolve_variable: 547.00µs
parser_10000_100 (48.47ms): Running very long AIR script with lot of variables and assignments
air::runner::execute_air: 48.47ms
farewell_step::outcome::from_success_result: 4.70ms
populate_outcome_from_contexts: 3.48ms
to_vec(call_results): 105.00µs
to_vec(data): 1.60ms
preparation_step::preparation::prepare: 34.34ms
air::preparation_step::preparation::make_exec_ctx: 1.41ms
air_parser::parser::air_parser::parse: 29.66ms
runner::execute: 4.39ms
execute: 2.00ms
execute: 483.00µs
new: 471.00µs
chore(bench): add bench results (#469) add bench results for current Marine
2023-02-14 12:45:43 +03:00
Machine 62dabcde478dc58760ebbe71ef6047299144a5f63990c6c3d826ebf30175adfc:
Platform: Linux-5.15.0-60-generic-x86_64-with-glibc2.35
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
Timestamp: 2023-02-14 10:33:54.321822+00:00
chore(bench): add bench results (#469) add bench results for current Marine
2023-02-14 12:45:43 +03:00
AquaVM version: 0.35.1
Benches:
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
big_values_data (12.75ms): Loading a trace with huge values
air::runner::execute_air: 12.75ms
farewell_step::outcome::from_success_result: 5.85ms
populate_outcome_from_contexts: 5.78ms
to_vec(call_results): 18.00µs
to_vec(data): 4.51ms
preparation_step::preparation::prepare: 6.78ms
air::preparation_step::preparation::make_exec_ctx: 29.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 6.62ms
air_parser::parser::air_parser::parse: 22.00µs
runner::execute: 11.00µs
dashboard (146.20ms): big dashboard test
air::runner::execute_air: 146.20ms
farewell_step::outcome::from_success_result: 522.00µs
populate_outcome_from_contexts: 441.00µs
to_vec(call_results): 39.00µs
to_vec(data): 212.00µs
preparation_step::preparation::prepare: 697.00µs
chore(bench): add bench results (#469) add bench results for current Marine
2023-02-14 12:45:43 +03:00
air::preparation_step::preparation::make_exec_ctx: 27.00µs
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
air_interpreter_data::interpreter_data::serde_json::from_slice: 402.00µs
air_parser::parser::air_parser::parse: 121.00µs
runner::execute: 145.10ms
execute: 131.22ms
execute: 13.68ms
instructions::call::resolved_call::prepare_request_params: 959.00µs
instructions::call::resolved_call::serde_json::to_string(tetraplets): 41.00µs
resolver::resolve::resolve_ast_variable: 610.00µs
resolve_variable: 199.00µs
resolver::resolve::resolve_ast_variable: 1.75ms
resolve_variable: 555.00µs
new: 83.94ms
resolve_ast_scalar: 60.95ms
resolve_ast_variable: 36.93ms
resolve_variable: 11.76ms
long_data (3.41ms): Long data trace
air::runner::execute_air: 3.41ms
farewell_step::outcome::from_success_result: 1.07ms
populate_outcome_from_contexts: 1.00ms
to_vec(call_results): 20.00µs
to_vec(data): 540.00µs
preparation_step::preparation::prepare: 2.21ms
air::preparation_step::preparation::make_exec_ctx: 50.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 2.03ms
air_parser::parser::air_parser::parse: 21.00µs
runner::execute: 10.00µs
network_explore (11.17ms): 5 peers of network are discovered
air::runner::execute_air: 11.17ms
farewell_step::outcome::from_success_result: 306.00µs
populate_outcome_from_contexts: 228.00µs
to_vec(call_results): 32.00µs
to_vec(data): 62.00µs
preparation_step::preparation::prepare: 345.00µs
air::preparation_step::preparation::make_exec_ctx: 22.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 102.00µs
air_parser::parser::air_parser::parse: 74.00µs
runner::execute: 10.35ms
execute: 9.32ms
execute: 1.55ms
resolve_ast_variable: 592.00µs
resolve_variable: 189.00µs
new: 5.43ms
resolve_ast_scalar: 3.93ms
resolve_ast_variable: 2.38ms
resolve_variable: 766.00µs
parser_10000_100 (26.83ms): Running very long AIR script with lot of variables and assignments
air::runner::execute_air: 26.83ms
farewell_step::outcome::from_success_result: 205.00µs
populate_outcome_from_contexts: 149.00µs
chore(bench): add bench results (#469) add bench results for current Marine
2023-02-14 12:45:43 +03:00
to_vec(call_results): 28.00µs
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
to_vec(data): 33.00µs
preparation_step::preparation::prepare: 24.70ms
air::preparation_step::preparation::make_exec_ctx: 26.00µs
air_parser::parser::air_parser::parse: 24.55ms
runner::execute: 270.00µs
execute: 197.00µs
execute: 42.00µs
new: 42.00µs
chore(benchmarking): data generators for a set of map-related benchmarks [fixes VM-345] (#735)
2023-11-08 16:22:17 +03:00
Machine 88756ca30bfb93b0da6a64252adc98fc3e97e142c3b4970af3d2948fd66107b4:
Platform: Linux-6.5.9-arch2-1-x86_64-with-glibc2.35
Timestamp: 2023-11-08 08:53:43.189029+00:00
AquaVM version: 0.54.0
Benches:
Features:
big-values-data (19.60ms; 58.938 MiB, 58.938 MiB): Loading a trace with huge values
air::runner::execute_air: 19.60ms
preparation_step::preparation::parse_data: 6.99ms
from_slice: 6.92ms
preparation_step::preparation::prepare: 259.00µs
air::preparation_step::preparation::make_exec_ctx: 23.00µs
air_parser::parser::air_parser::parse: 21.00µs
runner::execute: 11.00µs
runner::farewell: 5.59ms
from_success_result: 5.55ms
populate_outcome_from_contexts: 5.49ms
signing_step::sign_produced_cids: 186.00µs
verification_step::verify: 6.38ms
verify: 5.75ms
canon-map-key-by-lens (16.20ms; 56.625 MiB, 56.625 MiB): benchmarking a map insert operation
air::runner::execute_air: 16.20ms
preparation_step::preparation::parse_data: 4.01ms
from_slice: 3.96ms
preparation_step::preparation::prepare: 613.00µs
air::preparation_step::preparation::make_exec_ctx: 347.00µs
air_parser::parser::air_parser::parse: 55.00µs
runner::execute: 2.76ms
runner::farewell: 3.22ms
from_success_result: 3.19ms
populate_outcome_from_contexts: 2.78ms
signing_step::sign_produced_cids: 186.00µs
verification_step::verify: 5.30ms
verify: 4.68ms
canon-map-key-element-by-lens (16.20ms; 56.625 MiB, 56.625 MiB): benchmarking a map insert operation
air::runner::execute_air: 16.20ms
preparation_step::preparation::parse_data: 3.98ms
from_slice: 3.93ms
preparation_step::preparation::prepare: 610.00µs
air::preparation_step::preparation::make_exec_ctx: 344.00µs
air_parser::parser::air_parser::parse: 56.00µs
runner::execute: 2.76ms
runner::farewell: 3.20ms
from_success_result: 3.18ms
populate_outcome_from_contexts: 2.78ms
signing_step::sign_produced_cids: 185.00µs
verification_step::verify: 5.30ms
verify: 4.68ms
canon-map-multiple-keys (13.20ms; 54.500 MiB, 54.500 MiB): benchmarking a map insert operation
air::runner::execute_air: 13.20ms
preparation_step::preparation::parse_data: 349.00µs
from_slice: 306.00µs
preparation_step::preparation::prepare: 262.00µs
air::preparation_step::preparation::make_exec_ctx: 15.00µs
air_parser::parser::air_parser::parse: 44.00µs
runner::execute: 8.88ms
runner::farewell: 2.70ms
from_success_result: 2.68ms
populate_outcome_from_contexts: 2.36ms
signing_step::sign_produced_cids: 184.00µs
verification_step::verify: 636.00µs
verify: 26.00µs
canon-map-scalar-multiple-keys (5.52ms; 53.125 MiB, 53.125 MiB): benchmarking a map insert operation
air::runner::execute_air: 5.52ms
preparation_step::preparation::parse_data: 365.00µs
from_slice: 312.00µs
preparation_step::preparation::prepare: 284.00µs
air::preparation_step::preparation::make_exec_ctx: 19.00µs
air_parser::parser::air_parser::parse: 47.00µs
runner::execute: 3.34ms
runner::farewell: 536.00µs
from_success_result: 505.00µs
populate_outcome_from_contexts: 452.00µs
signing_step::sign_produced_cids: 191.00µs
verification_step::verify: 650.00µs
verify: 31.00µs
canon-map-scalar-single-key (4.46ms; 53.000 MiB, 53.000 MiB): benchmarking a map insert operation
air::runner::execute_air: 4.46ms
preparation_step::preparation::parse_data: 370.00µs
from_slice: 324.00µs
preparation_step::preparation::prepare: 262.00µs
air::preparation_step::preparation::make_exec_ctx: 16.00µs
air_parser::parser::air_parser::parse: 40.00µs
runner::execute: 2.32ms
runner::farewell: 513.00µs
from_success_result: 490.00µs
populate_outcome_from_contexts: 434.00µs
signing_step::sign_produced_cids: 185.00µs
verification_step::verify: 680.00µs
verify: 69.00µs
canon-map-single-key (11.30ms; 55.312 MiB, 55.312 MiB): benchmarking a map insert operation
air::runner::execute_air: 11.30ms
preparation_step::preparation::parse_data: 366.00µs
from_slice: 323.00µs
preparation_step::preparation::prepare: 257.00µs
air::preparation_step::preparation::make_exec_ctx: 15.00µs
air_parser::parser::air_parser::parse: 40.00µs
runner::execute: 6.70ms
runner::farewell: 3.01ms
from_success_result: 2.98ms
populate_outcome_from_contexts: 2.71ms
signing_step::sign_produced_cids: 185.00µs
verification_step::verify: 678.00µs
verify: 68.00µs
dashboard (10.70ms; 52.625 MiB, 52.625 MiB): big dashboard test
air::runner::execute_air: 10.70ms
preparation_step::preparation::parse_data: 1.43ms
from_slice: 1.37ms
preparation_step::preparation::prepare: 384.00µs
air::preparation_step::preparation::make_exec_ctx: 41.00µs
air_parser::parser::air_parser::parse: 135.00µs
runner::execute: 2.28ms
to_string(tetraplets): 471.00µs
runner::farewell: 834.00µs
from_success_result: 810.00µs
populate_outcome_from_contexts: 753.00µs
signing_step::sign_produced_cids: 187.00µs
verification_step::verify: 5.46ms
verify: 223.00µs
long-data (6.81ms; 53.812 MiB, 53.812 MiB): Long data trace
air::runner::execute_air: 6.81ms
preparation_step::preparation::parse_data: 2.40ms
from_slice: 2.35ms
preparation_step::preparation::prepare: 264.00µs
air::preparation_step::preparation::make_exec_ctx: 44.00µs
air_parser::parser::air_parser::parse: 17.00µs
runner::execute: 10.00µs
runner::farewell: 1.17ms
from_success_result: 1.15ms
populate_outcome_from_contexts: 1.11ms
signing_step::sign_produced_cids: 190.00µs
verification_step::verify: 2.65ms
verify: 949.00µs
multiple-cids10 (3.78ms; 52.438 MiB, 52.438 MiB): verifying multiple CIDs for single peer
air::runner::execute_air: 3.78ms
preparation_step::preparation::parse_data: 495.00µs
from_slice: 435.00µs
preparation_step::preparation::prepare: 286.00µs
air::preparation_step::preparation::make_exec_ctx: 34.00µs
air_parser::parser::air_parser::parse: 44.00µs
runner::execute: 578.00µs
to_string(tetraplets): 14.00µs
runner::farewell: 537.00µs
from_success_result: 513.00µs
populate_outcome_from_contexts: 452.00µs
signing_step::sign_produced_cids: 185.00µs
verification_step::verify: 1.57ms
verify: 259.00µs
multiple-peers8 (15.50ms; 53.375 MiB, 53.375 MiB): verifying many CIDs for many peers
air::runner::execute_air: 15.50ms
preparation_step::preparation::parse_data: 1.85ms
from_slice: 1.78ms
preparation_step::preparation::prepare: 408.00µs
air::preparation_step::preparation::make_exec_ctx: 143.00µs
air_parser::parser::air_parser::parse: 51.00µs
runner::execute: 3.92ms
to_string(tetraplets): 17.00µs
runner::farewell: 1.59ms
from_success_result: 1.56ms
populate_outcome_from_contexts: 1.44ms
signing_step::sign_produced_cids: 193.00µs
verification_step::verify: 7.44ms
verify: 1.23ms
multiple-sigs30 (26.00ms; 56.188 MiB, 56.188 MiB): signing multiple CIDs
air::runner::execute_air: 26.00ms
preparation_step::preparation::parse_data: 5.05ms
from_slice: 4.98ms
preparation_step::preparation::prepare: 500.00µs
air::preparation_step::preparation::make_exec_ctx: 230.00µs
air_parser::parser::air_parser::parse: 57.00µs
runner::execute: 10.30ms
runner::farewell: 4.21ms
from_success_result: 4.18ms
populate_outcome_from_contexts: 3.99ms
signing_step::sign_produced_cids: 781.00µs
verification_step::verify: 5.00ms
verify: 2.14ms
network-explore (5.14ms; 52.375 MiB, 52.375 MiB): 5 peers of network are discovered
air::runner::execute_air: 5.14ms
preparation_step::preparation::parse_data: 666.00µs
from_slice: 603.00µs
preparation_step::preparation::prepare: 299.00µs
air::preparation_step::preparation::make_exec_ctx: 22.00µs
air_parser::parser::air_parser::parse: 65.00µs
runner::execute: 187.00µs
to_string(tetraplets): 14.00µs
runner::farewell: 459.00µs
from_success_result: 434.00µs
populate_outcome_from_contexts: 388.00µs
signing_step::sign_produced_cids: 200.00µs
verification_step::verify: 3.20ms
verify: 66.00µs
populate-map (3.81ms; 51.938 MiB, 51.938 MiB): benchmarking a map insert operation
air::runner::execute_air: 3.81ms
preparation_step::preparation::parse_data: 130.00µs
from_slice: 91.00µs
preparation_step::preparation::prepare: 278.00µs
air::preparation_step::preparation::make_exec_ctx: 16.00µs
air_parser::parser::air_parser::parse: 49.00µs
runner::execute: 2.83ms
runner::farewell: 423.00µs
from_success_result: 398.00µs
populate_outcome_from_contexts: 349.00µs
signing_step::sign_produced_cids: 10.00µs
verification_step::verify: 13.00µs
populate-map-multiple-keys (4.63ms; 53.000 MiB, 53.000 MiB): benchmarking a map insert operation
air::runner::execute_air: 4.63ms
preparation_step::preparation::parse_data: 139.00µs
from_slice: 94.00µs
preparation_step::preparation::prepare: 266.00µs
air::preparation_step::preparation::make_exec_ctx: 16.00µs
air_parser::parser::air_parser::parse: 47.00µs
runner::execute: 2.83ms
runner::farewell: 439.00µs
from_success_result: 416.00µs
populate_outcome_from_contexts: 373.00µs
signing_step::sign_produced_cids: 184.00µs
verification_step::verify: 636.00µs
verify: 26.00µs
populate-map-single-key (3.77ms; 52.875 MiB, 52.875 MiB): benchmarking a map insert operation
air::runner::execute_air: 3.77ms
preparation_step::preparation::parse_data: 195.00µs
from_slice: 152.00µs
preparation_step::preparation::prepare: 263.00µs
air::preparation_step::preparation::make_exec_ctx: 16.00µs
air_parser::parser::air_parser::parse: 43.00µs
runner::execute: 1.86ms
runner::farewell: 456.00µs
from_success_result: 433.00µs
populate_outcome_from_contexts: 378.00µs
signing_step::sign_produced_cids: 185.00µs
verification_step::verify: 684.00µs
verify: 68.00µs
chore(bench): add bench results (#464) add bench results
2023-02-13 15:34:26 +03:00
Machine c1f3ea5950db0a10b44da931c25774d64ab25084f47d504f72f311e694550ff1:
Platform: macOS-12.0.1-x86_64-i386-64bit
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
Timestamp: 2023-02-13 13:19:34.106863+00:00
chore(bench): add bench results (#464) add bench results
2023-02-13 15:34:26 +03:00
AquaVM version: 0.35.1
Benches:
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
big_values_data (16.56ms): Loading a trace with huge values
air::runner::execute_air: 16.56ms
farewell_step::outcome::from_success_result: 7.35ms
populate_outcome_from_contexts: 7.27ms
to_vec(call_results): 22.00µs
to_vec(data): 5.96ms
preparation_step::preparation::prepare: 8.97ms
air::preparation_step::preparation::make_exec_ctx: 46.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 8.65ms
air_parser::parser::air_parser::parse: 78.00µs
runner::execute: 19.00µs
dashboard (105.40ms): big dashboard test
air::runner::execute_air: 105.40ms
farewell_step::outcome::from_success_result: 549.00µs
populate_outcome_from_contexts: 488.00µs
chore(bench): sort items in text bench resutls (#466)
2023-02-13 19:55:03 +03:00
to_vec(call_results): 43.00µs
feat(avm)!: integrate Marine 0.26.0 (#461)
2023-03-15 17:11:53 +03:00
to_vec(data): 234.00µs
preparation_step::preparation::prepare: 1.31ms
air::preparation_step::preparation::make_exec_ctx: 64.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 737.00µs
air_parser::parser::air_parser::parse: 276.00µs
runner::execute: 103.00ms
execute: 92.47ms
execute: 9.52ms
instructions::call::resolved_call::prepare_request_params: 799.00µs
instructions::call::resolved_call::serde_json::to_string(tetraplets): 51.00µs
resolver::resolve::resolve_ast_variable: 460.00µs
resolve_variable: 145.00µs
resolver::resolve::resolve_ast_variable: 1.42ms
resolve_variable: 477.00µs
new: 59.93ms
resolve_ast_scalar: 44.46ms
resolve_ast_variable: 27.31ms
resolve_variable: 8.72ms
long_data (4.47ms): Long data trace
air::runner::execute_air: 4.47ms
farewell_step::outcome::from_success_result: 1.38ms
populate_outcome_from_contexts: 1.27ms
to_vec(call_results): 20.00µs
to_vec(data): 652.00µs
preparation_step::preparation::prepare: 2.82ms
air::preparation_step::preparation::make_exec_ctx: 64.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 2.53ms
air_parser::parser::air_parser::parse: 63.00µs
runner::execute: 25.00µs
network_explore (9.70ms): 5 peers of network are discovered
air::runner::execute_air: 9.70ms
farewell_step::outcome::from_success_result: 291.00µs
populate_outcome_from_contexts: 230.00µs
to_vec(call_results): 26.00µs
to_vec(data): 79.00µs
preparation_step::preparation::prepare: 847.00µs
air::preparation_step::preparation::make_exec_ctx: 64.00µs
air_interpreter_data::interpreter_data::serde_json::from_slice: 315.00µs
air_parser::parser::air_parser::parse: 206.00µs
runner::execute: 8.29ms
execute: 7.28ms
execute: 1.28ms
resolve_ast_variable: 497.00µs
resolve_variable: 155.00µs
new: 4.24ms
resolve_ast_scalar: 2.99ms
resolve_ast_variable: 1.81ms
resolve_variable: 569.00µs
parser_10000_100 (33.06ms): Running very long AIR script with lot of variables and assignments
air::runner::execute_air: 33.06ms
farewell_step::outcome::from_success_result: 207.00µs
populate_outcome_from_contexts: 158.00µs
to_vec(call_results): 18.00µs
to_vec(data): 47.00µs
preparation_step::preparation::prepare: 30.52ms
air::preparation_step::preparation::make_exec_ctx: 63.00µs
air_parser::parser::air_parser::parse: 30.28ms
runner::execute: 270.00µs
execute: 167.00µs
execute: 29.00µs
new: 38.00µs
feat(tools): VM-194 performance metering (#440) * Experimental performance metering * Average on repeated runs with `--repeat` option * Add "version" field to the report The version is got from `air/Cargo.toml`. * Allow disabling preparing binaries with the `--no-prepare-binaries` option. * Human-readable execution time in the report * Add dashboard benchmark * Human-readable text report
2023-02-03 23:26:06 +07:00
Machine d77ebe8481884bc3b2778c8083f1bf459e548e929edd87041beb14f6b868d35f:
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
Platform: macOS-14.1.2-arm64-arm-64bit
Timestamp: 2023-12-12 10:20:35.572977+00:00
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
AquaVM version: 0.54.0
feat(aquavm-air)!: signature checking (#607)
2023-10-13 23:19:02 +04:00
Benches:
Features: check_signatures,gen_signatures
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
big-values-data (13.10ms; 59.000 MiB, 59.000 MiB): Loading a trace with huge values
air::runner::execute_air: 13.10ms
preparation_step::preparation::parse_data: 5.36ms
from_slice: 5.30ms
preparation_step::preparation::prepare: 170.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air::preparation_step::preparation::make_exec_ctx: 22.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
air_parser::parser::air_parser::parse: 32.00µs
runner::execute: 8.00µs
runner::farewell: 3.29ms
from_success_result: 3.27ms
populate_outcome_from_contexts: 3.23ms
signing_step::sign_produced_cids: 100.00µs
verification_step::verify: 3.99ms
verify: 3.63ms
call-requests500 (26.11ms; 58.562 MiB, 58.562 MiB): multiple call requests
air::runner::execute_air: 26.11ms
preparation_step::preparation::parse_data: 134.00µs
from_slice: 97.00µs
preparation_step::preparation::prepare: 238.00µs
air::preparation_step::preparation::make_exec_ctx: 48.00µs
air_parser::parser::air_parser::parse: 68.00µs
runner::execute: 20.23ms
runner::farewell: 5.16ms
from_success_result: 5.14ms
populate_outcome_from_contexts: 5.04ms
signing_step::sign_produced_cids: 107.00µs
verification_step::verify: 75.00µs
verify: 9.00µs
call-results500 (15.96ms; 54.438 MiB, 54.438 MiB): multiple call results
air::runner::execute_air: 15.96ms
preparation_step::preparation::parse_data: 624.00µs
from_slice: 581.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
preparation_step::preparation::prepare: 1.00ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
air::preparation_step::preparation::make_exec_ctx: 810.00µs
air_parser::parser::air_parser::parse: 67.00µs
runner::execute: 11.94ms
runner::farewell: 1.82ms
from_success_result: 1.79ms
populate_outcome_from_contexts: 1.35ms
signing_step::sign_produced_cids: 292.00µs
verification_step::verify: 92.00µs
verify: 9.00µs
canon-map-key-by-lens (10.80ms; 56.625 MiB, 56.625 MiB): benchmarking a map insert operation
air::runner::execute_air: 10.80ms
preparation_step::preparation::parse_data: 3.18ms
from_slice: 3.13ms
preparation_step::preparation::prepare: 378.00µs
air::preparation_step::preparation::make_exec_ctx: 189.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air_parser::parser::air_parser::parse: 73.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::execute: 1.94ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
runner::farewell: 1.87ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
from_success_result: 1.85ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
populate_outcome_from_contexts: 1.49ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
signing_step::sign_produced_cids: 99.00µs
verification_step::verify: 3.15ms
verify: 2.79ms
canon-map-key-element-by-lens (10.80ms; 56.625 MiB, 56.625 MiB): benchmarking a map insert operation
air::runner::execute_air: 10.80ms
preparation_step::preparation::parse_data: 3.18ms
from_slice: 3.13ms
preparation_step::preparation::prepare: 387.00µs
air::preparation_step::preparation::make_exec_ctx: 194.00µs
air_parser::parser::air_parser::parse: 75.00µs
runner::execute: 1.93ms
runner::farewell: 1.86ms
from_success_result: 1.84ms
populate_outcome_from_contexts: 1.50ms
signing_step::sign_produced_cids: 99.00µs
verification_step::verify: 3.15ms
verify: 2.79ms
canon-map-multiple-keys (8.97ms; 54.500 MiB, 54.500 MiB): benchmarking a map insert operation
air::runner::execute_air: 8.97ms
preparation_step::preparation::parse_data: 410.00µs
from_slice: 363.00µs
preparation_step::preparation::prepare: 196.00µs
air::preparation_step::preparation::make_exec_ctx: 20.00µs
air_parser::parser::air_parser::parse: 59.00µs
runner::execute: 6.05ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
runner::farewell: 1.63ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
from_success_result: 1.60ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
populate_outcome_from_contexts: 1.32ms
signing_step::sign_produced_cids: 100.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verification_step::verify: 406.00µs
verify: 39.00µs
canon-map-scalar-multiple-keys (4.10ms; 53.125 MiB, 53.125 MiB): benchmarking a map insert operation
air::runner::execute_air: 4.10ms
preparation_step::preparation::parse_data: 420.00µs
from_slice: 369.00µs
preparation_step::preparation::prepare: 195.00µs
air::preparation_step::preparation::make_exec_ctx: 20.00µs
air_parser::parser::air_parser::parse: 59.00µs
runner::execute: 2.45ms
runner::farewell: 349.00µs
from_success_result: 329.00µs
populate_outcome_from_contexts: 292.00µs
signing_step::sign_produced_cids: 99.00µs
verification_step::verify: 406.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
verify: 40.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
canon-map-scalar-single-key (3.26ms; 53.000 MiB, 53.000 MiB): benchmarking a map insert operation
air::runner::execute_air: 3.26ms
preparation_step::preparation::parse_data: 423.00µs
from_slice: 375.00µs
preparation_step::preparation::prepare: 192.00µs
air::preparation_step::preparation::make_exec_ctx: 19.00µs
air_parser::parser::air_parser::parse: 56.00µs
runner::execute: 1.57ms
runner::farewell: 359.00µs
from_success_result: 339.00µs
populate_outcome_from_contexts: 284.00µs
signing_step::sign_produced_cids: 99.00µs
verification_step::verify: 435.00µs
verify: 73.00µs
canon-map-single-key (7.48ms; 55.312 MiB, 55.312 MiB): benchmarking a map insert operation
air::runner::execute_air: 7.48ms
preparation_step::preparation::parse_data: 421.00µs
from_slice: 373.00µs
preparation_step::preparation::prepare: 192.00µs
air::preparation_step::preparation::make_exec_ctx: 20.00µs
air_parser::parser::air_parser::parse: 56.00µs
runner::execute: 4.44ms
runner::farewell: 1.72ms
from_success_result: 1.70ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
populate_outcome_from_contexts: 1.46ms
signing_step::sign_produced_cids: 99.00µs
verification_step::verify: 434.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verify: 72.00µs
dashboard (5.69ms; 52.625 MiB, 52.625 MiB): big dashboard test
air::runner::execute_air: 5.69ms
preparation_step::preparation::parse_data: 1.01ms
from_slice: 955.00µs
preparation_step::preparation::prepare: 313.00µs
air::preparation_step::preparation::make_exec_ctx: 36.00µs
air_parser::parser::air_parser::parse: 160.00µs
runner::execute: 759.00µs
runner::farewell: 461.00µs
from_success_result: 441.00µs
populate_outcome_from_contexts: 398.00µs
signing_step::sign_produced_cids: 101.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
verification_step::verify: 2.87ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verify: 157.00µs
long-data (5.01ms; 53.812 MiB, 53.812 MiB): Long data trace
air::runner::execute_air: 5.01ms
preparation_step::preparation::parse_data: 1.95ms
from_slice: 1.89ms
preparation_step::preparation::prepare: 182.00µs
air::preparation_step::preparation::make_exec_ctx: 34.00µs
air_parser::parser::air_parser::parse: 31.00µs
runner::execute: 8.00µs
runner::farewell: 895.00µs
from_success_result: 876.00µs
populate_outcome_from_contexts: 838.00µs
signing_step::sign_produced_cids: 98.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
verification_step::verify: 1.71ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verify: 662.00µs
multiple-cids10 (2.53ms; 52.438 MiB, 52.438 MiB): verifying multiple CIDs for single peer
air::runner::execute_air: 2.53ms
preparation_step::preparation::parse_data: 425.00µs
from_slice: 371.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
preparation_step::preparation::prepare: 206.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
air::preparation_step::preparation::make_exec_ctx: 30.00µs
air_parser::parser::air_parser::parse: 60.00µs
runner::execute: 418.00µs
runner::farewell: 320.00µs
from_success_result: 299.00µs
populate_outcome_from_contexts: 249.00µs
signing_step::sign_produced_cids: 99.00µs
verification_step::verify: 890.00µs
verify: 180.00µs
multiple-peers8 (9.43ms; 53.375 MiB, 53.375 MiB): verifying many CIDs for many peers
air::runner::execute_air: 9.43ms
preparation_step::preparation::parse_data: 1.38ms
from_slice: 1.33ms
preparation_step::preparation::prepare: 258.00µs
air::preparation_step::preparation::make_exec_ctx: 78.00µs
air_parser::parser::air_parser::parse: 64.00µs
runner::execute: 2.68ms
runner::farewell: 896.00µs
from_success_result: 875.00µs
populate_outcome_from_contexts: 774.00µs
signing_step::sign_produced_cids: 99.00µs
verification_step::verify: 3.93ms
verify: 733.00µs
multiple-sigs30 (17.47ms; 56.188 MiB, 56.188 MiB): signing multiple CIDs
air::runner::execute_air: 17.47ms
preparation_step::preparation::parse_data: 3.96ms
from_slice: 3.90ms
preparation_step::preparation::prepare: 330.00µs
air::preparation_step::preparation::make_exec_ctx: 151.00µs
air_parser::parser::air_parser::parse: 63.00µs
runner::execute: 7.04ms
runner::farewell: 2.55ms
from_success_result: 2.53ms
populate_outcome_from_contexts: 2.35ms
signing_step::sign_produced_cids: 443.00µs
verification_step::verify: 2.96ms
verify: 1.26ms
network-explore (3.07ms; 52.375 MiB, 52.375 MiB): 5 peers of network are discovered
air::runner::execute_air: 3.07ms
preparation_step::preparation::parse_data: 490.00µs
from_slice: 434.00µs
preparation_step::preparation::prepare: 219.00µs
air::preparation_step::preparation::make_exec_ctx: 25.00µs
air_parser::parser::air_parser::parse: 78.00µs
runner::execute: 144.00µs
runner::farewell: 251.00µs
from_success_result: 231.00µs
populate_outcome_from_contexts: 193.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
signing_step::sign_produced_cids: 100.00µs
verification_step::verify: 1.69ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verify: 65.00µs
null (737.00µs; 52.375 MiB, 52.375 MiB): Empty data and null script
air::runner::execute_air: 737.00µs
preparation_step::preparation::parse_data: 23.00µs
preparation_step::preparation::prepare: 190.00µs
air::preparation_step::preparation::make_exec_ctx: 23.00µs
chore(benchmark): clear stale benchmark data (#763) * chore(benchmark): clear stale benchmark data Originally, benchmark util merge benchmark data, i.e. only inserted new data in the benchmark store. However, sometimes benches disappear, and incorrect information is stored for them (i.e. AquaVM version which is per-machine). However, sometimes this functionality is useful, when you want to add a new benchmark without running all the others. For such case, `aquavm_performance_metergin run --unsafe-merge-results` option is added. * Restore the `null` benchmark * Do text report generation exactly one time It was regenerated from 0 to N times before, and it is wrong.
2023-12-04 17:26:22 +04:00
air_parser::parser::air_parser::parse: 34.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::execute: 8.00µs
runner::farewell: 184.00µs
from_success_result: 165.00µs
chore(benchmark): clear stale benchmark data (#763) * chore(benchmark): clear stale benchmark data Originally, benchmark util merge benchmark data, i.e. only inserted new data in the benchmark store. However, sometimes benches disappear, and incorrect information is stored for them (i.e. AquaVM version which is per-machine). However, sometimes this functionality is useful, when you want to add a new benchmark without running all the others. For such case, `aquavm_performance_metergin run --unsafe-merge-results` option is added. * Restore the `null` benchmark * Do text report generation exactly one time It was regenerated from 0 to N times before, and it is wrong.
2023-12-04 17:26:22 +04:00
populate_outcome_from_contexts: 125.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
signing_step::sign_produced_cids: 106.00µs
chore(benchmark): clear stale benchmark data (#763) * chore(benchmark): clear stale benchmark data Originally, benchmark util merge benchmark data, i.e. only inserted new data in the benchmark store. However, sometimes benches disappear, and incorrect information is stored for them (i.e. AquaVM version which is per-machine). However, sometimes this functionality is useful, when you want to add a new benchmark without running all the others. For such case, `aquavm_performance_metergin run --unsafe-merge-results` option is added. * Restore the `null` benchmark * Do text report generation exactly one time It was regenerated from 0 to N times before, and it is wrong.
2023-12-04 17:26:22 +04:00
verification_step::verify: 44.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verify: 10.00µs
parser-10000-100 (22.89ms; 54.625 MiB, 54.625 MiB): long air script with lot of variable assignments
air::runner::execute_air: 22.89ms
preparation_step::preparation::parse_data: 25.00µs
preparation_step::preparation::prepare: 21.40ms
air::preparation_step::preparation::make_exec_ctx: 23.00µs
air_parser::parser::air_parser::parse: 21.25ms
runner::execute: 39.00µs
runner::farewell: 187.00µs
chore(benchmark): restore parser-10000-100 bench (#762) A benchmark with empty datas that has long AIR code with lot of variable (re-)assignments.
2023-11-30 17:33:41 +04:00
from_success_result: 168.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
populate_outcome_from_contexts: 131.00µs
signing_step::sign_produced_cids: 107.00µs
verification_step::verify: 45.00µs
verify: 11.00µs
parser-calls-10000-100 (22.65ms; 54.375 MiB, 54.375 MiB): multiple calls parser benchmark
air::runner::execute_air: 22.65ms
preparation_step::preparation::parse_data: 25.00µs
preparation_step::preparation::prepare: 21.00ms
air::preparation_step::preparation::make_exec_ctx: 25.00µs
air_parser::parser::air_parser::parse: 20.84ms
runner::execute: 39.00µs
runner::farewell: 187.00µs
from_success_result: 168.00µs
populate_outcome_from_contexts: 130.00µs
signing_step::sign_produced_cids: 107.00µs
verification_step::verify: 42.00µs
verify: 10.00µs
populate-map-multiple-keys (3.45ms; 53.000 MiB, 53.000 MiB): benchmarking a map insert operation
air::runner::execute_air: 3.45ms
preparation_step::preparation::parse_data: 162.00µs
from_slice: 113.00µs
preparation_step::preparation::prepare: 196.00µs
air::preparation_step::preparation::make_exec_ctx: 19.00µs
air_parser::parser::air_parser::parse: 60.00µs
runner::execute: 2.14ms
runner::farewell: 285.00µs
from_success_result: 266.00µs
populate_outcome_from_contexts: 231.00µs
signing_step::sign_produced_cids: 100.00µs
verification_step::verify: 392.00µs
verify: 39.00µs
populate-map-single-key (2.73ms; 52.938 MiB, 52.938 MiB): benchmarking a map insert operation
air::runner::execute_air: 2.73ms
preparation_step::preparation::parse_data: 215.00µs
from_slice: 168.00µs
preparation_step::preparation::prepare: 195.00µs
air::preparation_step::preparation::make_exec_ctx: 20.00µs
air_parser::parser::air_parser::parse: 60.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
runner::execute: 1.30ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::farewell: 308.00µs
from_success_result: 289.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
populate_outcome_from_contexts: 235.00µs
signing_step::sign_produced_cids: 99.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verification_step::verify: 425.00µs
verify: 74.00µs
feat(aquavm-air)!: signature checking (#607)
2023-10-13 23:19:02 +04:00
Machine e536f8eaae8c978493a773ba566ae3393e2e6240d6ea8e05b5ca1b8f77e9c441:
Platform: Linux-5.15.0-76-generic-x86_64-with-glibc2.29
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
Timestamp: 2023-12-12 12:01:06.070549+00:00
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
AquaVM version: 0.54.0
feat(aquavm-air)!: signature checking (#607)
2023-10-13 23:19:02 +04:00
Benches:
Features: check_signatures,gen_signatures
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
big-values-data (17.84ms; 59.000 MiB, 59.000 MiB): Loading a trace with huge values
air::runner::execute_air: 17.84ms
preparation_step::preparation::parse_data: 7.24ms
from_slice: 7.19ms
preparation_step::preparation::prepare: 222.00µs
air::preparation_step::preparation::make_exec_ctx: 21.00µs
air_parser::parser::air_parser::parse: 19.00µs
feat(aquavm-air)!: signature checking (#607)
2023-10-13 23:19:02 +04:00
runner::execute: 10.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::farewell: 4.70ms
from_success_result: 4.67ms
populate_outcome_from_contexts: 4.61ms
signing_step::sign_produced_cids: 158.00µs
verification_step::verify: 5.35ms
verify: 4.81ms
call-requests500 (35.41ms; 58.562 MiB, 58.562 MiB): multiple call requests
air::runner::execute_air: 35.41ms
preparation_step::preparation::parse_data: 112.00µs
from_slice: 76.00µs
preparation_step::preparation::prepare: 270.00µs
air::preparation_step::preparation::make_exec_ctx: 40.00µs
air_parser::parser::air_parser::parse: 48.00µs
runner::execute: 25.35ms
runner::farewell: 9.31ms
from_success_result: 9.29ms
populate_outcome_from_contexts: 9.14ms
signing_step::sign_produced_cids: 165.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
verification_step::verify: 77.00µs
verify: 10.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
call-results500 (19.57ms; 54.438 MiB, 54.438 MiB): multiple call results
air::runner::execute_air: 19.57ms
preparation_step::preparation::parse_data: 667.00µs
from_slice: 627.00µs
preparation_step::preparation::prepare: 931.00µs
air::preparation_step::preparation::make_exec_ctx: 694.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air_parser::parser::air_parser::parse: 50.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::execute: 15.12ms
runner::farewell: 2.20ms
from_success_result: 2.17ms
populate_outcome_from_contexts: 1.75ms
signing_step::sign_produced_cids: 432.00µs
verification_step::verify: 82.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
verify: 10.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
canon-map-key-by-lens (14.97ms; 56.625 MiB, 56.625 MiB): benchmarking a map insert operation
air::runner::execute_air: 14.97ms
preparation_step::preparation::parse_data: 4.08ms
from_slice: 4.03ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
preparation_step::preparation::prepare: 530.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
air::preparation_step::preparation::make_exec_ctx: 289.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air_parser::parser::air_parser::parse: 57.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::execute: 2.75ms
runner::farewell: 2.78ms
from_success_result: 2.76ms
populate_outcome_from_contexts: 2.39ms
signing_step::sign_produced_cids: 160.00µs
verification_step::verify: 4.52ms
verify: 3.98ms
canon-map-key-element-by-lens (14.92ms; 56.625 MiB, 56.625 MiB): benchmarking a map insert operation
air::runner::execute_air: 14.92ms
preparation_step::preparation::parse_data: 4.09ms
from_slice: 4.04ms
preparation_step::preparation::prepare: 526.00µs
air::preparation_step::preparation::make_exec_ctx: 285.00µs
air_parser::parser::air_parser::parse: 58.00µs
runner::execute: 2.73ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
runner::farewell: 2.78ms
from_success_result: 2.75ms
populate_outcome_from_contexts: 2.40ms
feat(interpreter-cid)!: use Blake3 for CIDs (#729) Change to more efficient cryptography hash implementation.
2023-10-23 17:16:15 +04:00
signing_step::sign_produced_cids: 161.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verification_step::verify: 4.51ms
verify: 3.97ms
canon-map-multiple-keys (12.43ms; 54.500 MiB, 54.500 MiB): benchmarking a map insert operation
air::runner::execute_air: 12.43ms
preparation_step::preparation::parse_data: 355.00µs
from_slice: 313.00µs
preparation_step::preparation::prepare: 247.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air::preparation_step::preparation::make_exec_ctx: 18.00µs
air_parser::parser::air_parser::parse: 46.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::execute: 8.64ms
runner::farewell: 2.31ms
from_success_result: 2.28ms
populate_outcome_from_contexts: 1.99ms
signing_step::sign_produced_cids: 164.00µs
verification_step::verify: 566.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
verify: 28.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
canon-map-scalar-multiple-keys (5.33ms; 53.125 MiB, 53.125 MiB): benchmarking a map insert operation
air::runner::execute_air: 5.33ms
preparation_step::preparation::parse_data: 358.00µs
from_slice: 316.00µs
preparation_step::preparation::prepare: 244.00µs
air::preparation_step::preparation::make_exec_ctx: 18.00µs
air_parser::parser::air_parser::parse: 45.00µs
runner::execute: 3.40ms
runner::farewell: 460.00µs
from_success_result: 438.00µs
populate_outcome_from_contexts: 394.00µs
signing_step::sign_produced_cids: 161.00µs
verification_step::verify: 576.00µs
verify: 27.00µs
canon-map-scalar-single-key (4.35ms; 53.000 MiB, 53.000 MiB): benchmarking a map insert operation
air::runner::execute_air: 4.35ms
preparation_step::preparation::parse_data: 387.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
from_slice: 342.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
preparation_step::preparation::prepare: 244.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air::preparation_step::preparation::make_exec_ctx: 18.00µs
air_parser::parser::air_parser::parse: 43.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::execute: 2.35ms
runner::farewell: 462.00µs
from_success_result: 438.00µs
populate_outcome_from_contexts: 380.00µs
signing_step::sign_produced_cids: 165.00µs
verification_step::verify: 599.00µs
verify: 62.00µs
canon-map-single-key (10.81ms; 55.312 MiB, 55.312 MiB): benchmarking a map insert operation
air::runner::execute_air: 10.81ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
preparation_step::preparation::parse_data: 381.00µs
from_slice: 340.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
preparation_step::preparation::prepare: 239.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air::preparation_step::preparation::make_exec_ctx: 18.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
air_parser::parser::air_parser::parse: 43.00µs
runner::execute: 6.62ms
runner::farewell: 2.68ms
from_success_result: 2.66ms
populate_outcome_from_contexts: 2.40ms
signing_step::sign_produced_cids: 160.00µs
verification_step::verify: 590.00µs
verify: 61.00µs
dashboard (8.65ms; 52.625 MiB, 52.625 MiB): big dashboard test
air::runner::execute_air: 8.65ms
preparation_step::preparation::parse_data: 1.32ms
from_slice: 1.26ms
preparation_step::preparation::prepare: 360.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air::preparation_step::preparation::make_exec_ctx: 41.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
air_parser::parser::air_parser::parse: 132.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
runner::execute: 1.08ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::farewell: 674.00µs
from_success_result: 650.00µs
populate_outcome_from_contexts: 596.00µs
signing_step::sign_produced_cids: 172.00µs
verification_step::verify: 4.89ms
verify: 198.00µs
long-data (6.29ms; 53.812 MiB, 53.812 MiB): Long data trace
air::runner::execute_air: 6.29ms
preparation_step::preparation::parse_data: 2.44ms
from_slice: 2.40ms
preparation_step::preparation::prepare: 239.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air::preparation_step::preparation::make_exec_ctx: 41.00µs
chore(benchmarking): data generators for a set of map-related benchmarks [fixes VM-345] (#735)
2023-11-08 16:22:17 +03:00
air_parser::parser::air_parser::parse: 18.00µs
feat(interpreter-cid)!: use Blake3 for CIDs (#729) Change to more efficient cryptography hash implementation.
2023-10-23 17:16:15 +04:00
runner::execute: 9.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::farewell: 1.09ms
from_success_result: 1.07ms
populate_outcome_from_contexts: 1.03ms
signing_step::sign_produced_cids: 160.00µs
verification_step::verify: 2.23ms
verify: 838.00µs
multiple-cids10 (3.43ms; 52.438 MiB, 52.438 MiB): verifying multiple CIDs for single peer
air::runner::execute_air: 3.43ms
preparation_step::preparation::parse_data: 478.00µs
from_slice: 423.00µs
preparation_step::preparation::prepare: 260.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air::preparation_step::preparation::make_exec_ctx: 32.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
air_parser::parser::air_parser::parse: 45.00µs
runner::execute: 572.00µs
runner::farewell: 464.00µs
from_success_result: 441.00µs
populate_outcome_from_contexts: 383.00µs
signing_step::sign_produced_cids: 162.00µs
verification_step::verify: 1.36ms
verify: 233.00µs
multiple-peers8 (13.67ms; 53.375 MiB, 53.375 MiB): verifying many CIDs for many peers
air::runner::execute_air: 13.67ms
preparation_step::preparation::parse_data: 1.77ms
from_slice: 1.71ms
preparation_step::preparation::prepare: 338.00µs
air::preparation_step::preparation::make_exec_ctx: 104.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air_parser::parser::air_parser::parse: 51.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::execute: 3.68ms
chore(benchmarking): data generators for a set of map-related benchmarks [fixes VM-345] (#735)
2023-11-08 16:22:17 +03:00
runner::farewell: 1.30ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
from_success_result: 1.28ms
populate_outcome_from_contexts: 1.17ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
signing_step::sign_produced_cids: 162.00µs
verification_step::verify: 6.26ms
verify: 1.04ms
multiple-sigs30 (24.71ms; 56.188 MiB, 56.188 MiB): signing multiple CIDs
air::runner::execute_air: 24.71ms
preparation_step::preparation::parse_data: 5.05ms
from_slice: 4.98ms
preparation_step::preparation::prepare: 444.00µs
air::preparation_step::preparation::make_exec_ctx: 208.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
air_parser::parser::air_parser::parse: 49.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::execute: 10.47ms
runner::farewell: 3.69ms
from_success_result: 3.66ms
populate_outcome_from_contexts: 3.48ms
signing_step::sign_produced_cids: 654.00µs
verification_step::verify: 4.27ms
verify: 1.80ms
network-explore (4.40ms; 52.375 MiB, 52.375 MiB): 5 peers of network are discovered
air::runner::execute_air: 4.40ms
preparation_step::preparation::parse_data: 587.00µs
from_slice: 531.00µs
preparation_step::preparation::prepare: 273.00µs
air::preparation_step::preparation::make_exec_ctx: 23.00µs
air_parser::parser::air_parser::parse: 68.00µs
runner::execute: 159.00µs
runner::farewell: 369.00µs
from_success_result: 346.00µs
populate_outcome_from_contexts: 301.00µs
signing_step::sign_produced_cids: 162.00µs
verification_step::verify: 2.72ms
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
verify: 64.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
null (834.00µs; 52.375 MiB, 52.375 MiB): Empty data and null script
air::runner::execute_air: 834.00µs
preparation_step::preparation::parse_data: 19.00µs
chore(benchmarking): data generators for a set of map-related benchmarks [fixes VM-345] (#735)
2023-11-08 16:22:17 +03:00
preparation_step::preparation::prepare: 224.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
air::preparation_step::preparation::make_exec_ctx: 15.00µs
chore(benches): update benchmarks after 1024 stream limit (#728)
2023-10-20 18:00:19 +04:00
air_parser::parser::air_parser::parse: 19.00µs
chore(benchmarking): data generators for a set of map-related benchmarks [fixes VM-345] (#735)
2023-11-08 16:22:17 +03:00
runner::execute: 9.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
runner::farewell: 256.00µs
chore(benchmark): restore parser-10000-100 bench (#762) A benchmark with empty datas that has long AIR code with lot of variable (re-)assignments.
2023-11-30 17:33:41 +04:00
from_success_result: 235.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
populate_outcome_from_contexts: 195.00µs
chore(benchmark): restore parser-10000-100 bench (#762) A benchmark with empty datas that has long AIR code with lot of variable (re-)assignments.
2023-11-30 17:33:41 +04:00
signing_step::sign_produced_cids: 161.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verification_step::verify: 35.00µs
chore(benchmark): restore parser-10000-100 bench (#762) A benchmark with empty datas that has long AIR code with lot of variable (re-)assignments.
2023-11-30 17:33:41 +04:00
verify: 10.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
parser-10000-100 (28.73ms; 54.625 MiB, 54.625 MiB): long air script with lot of variable assignments
air::runner::execute_air: 28.73ms
preparation_step::preparation::parse_data: 20.00µs
preparation_step::preparation::prepare: 27.47ms
air::preparation_step::preparation::make_exec_ctx: 17.00µs
air_parser::parser::air_parser::parse: 27.23ms
runner::execute: 27.00µs
runner::farewell: 263.00µs
from_success_result: 240.00µs
populate_outcome_from_contexts: 201.00µs
signing_step::sign_produced_cids: 162.00µs
verification_step::verify: 36.00µs
verify: 10.00µs
parser-calls-10000-100 (25.94ms; 54.375 MiB, 54.375 MiB): multiple calls parser benchmark
air::runner::execute_air: 25.94ms
preparation_step::preparation::parse_data: 18.00µs
preparation_step::preparation::prepare: 24.66ms
air::preparation_step::preparation::make_exec_ctx: 15.00µs
air_parser::parser::air_parser::parse: 24.46ms
runner::execute: 28.00µs
runner::farewell: 255.00µs
from_success_result: 233.00µs
populate_outcome_from_contexts: 195.00µs
signing_step::sign_produced_cids: 160.00µs
verification_step::verify: 36.00µs
verify: 10.00µs
populate-map-multiple-keys (4.40ms; 53.000 MiB, 53.000 MiB): benchmarking a map insert operation
air::runner::execute_air: 4.40ms
preparation_step::preparation::parse_data: 131.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
from_slice: 91.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
preparation_step::preparation::prepare: 243.00µs
air::preparation_step::preparation::make_exec_ctx: 17.00µs
air_parser::parser::air_parser::parse: 48.00µs
runner::execute: 2.80ms
runner::farewell: 383.00µs
from_success_result: 361.00µs
populate_outcome_from_contexts: 321.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
signing_step::sign_produced_cids: 158.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verification_step::verify: 557.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
verify: 27.00µs
populate-map-single-key (3.62ms; 52.938 MiB, 52.938 MiB): benchmarking a map insert operation
air::runner::execute_air: 3.62ms
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
preparation_step::preparation::parse_data: 200.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
from_slice: 159.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
preparation_step::preparation::prepare: 244.00µs
air::preparation_step::preparation::make_exec_ctx: 17.00µs
air_parser::parser::air_parser::parse: 45.00µs
runner::execute: 1.89ms
runner::farewell: 403.00µs
from_success_result: 381.00µs
populate_outcome_from_contexts: 325.00µs
chore(benchmarks): call-requests and call-results benchmarks (#759)
2023-11-27 21:01:14 +04:00
signing_step::sign_produced_cids: 160.00µs
verification_step::verify: 586.00µs
feat(air-parser)!: optimize Instruction type layout (#767) Instead of being boxed for each node, the `Instruction` type contains a boxed variable-size elements. Thus `Instruction` is quite lean, and the allocator deals with variable-sized elements. Total number of allocations is more or less same, but less space is wasted for unused memory: previously the Instruction's size was 112 bytes in WASM, now it is 16. It reduces memory consumption on large AIR scripts (heap size decreased from 7.7MiB to 4.625MiB in parser-10000-100, and for the new parser-calls-10000-100 benchmark, it decreased from 5.115MiB to 4.375MiB). This is a breaking change as the API changes (though the code that navigates the parsed tree generally should work as is).
2023-12-12 16:50:41 +04:00
verify: 60.00µs
Reference in New Issue Copy Permalink