chore: CLI's startup time was pushing almost 2s. This gets the basic 'help' down to 0.16.

[charlielye]

• The CLI took 2s just to display the help (worse when launching via docker). Pretty frustrating.
• This is symptomatic of just a deeper issue, of exporting a lot of stuff, through a single import module, or just having too much code in one place.
• This improves our cli, getting simple printing of help down to ~0.16s. When running in docker we get a flat overhead of about 0.4s, giving us ~0.6s, which feels responsive enough. (~0.8 on mac)
• This is achieved via several techniques. Given that cli "does-almost-all-the-things", it basically needs to compile the entire codebase on startup if we naively import everything.
  • I've put every command action code into it's own file named after that action, under the cmds folder. This is just nicer anyway as we shouldn't be creating multiple 1000's line files.
  • The action file is then dynamically imported if that action is requested, so at that point in time, node will incur the import overhead.
  • In utils (please let's not name things utils, break it up into distinct groups with well named files), we use a new "granular" export api from aztec.js. The api isn't complete, it was just enough to import what was needed and get rid of about 200ms of overhead.
  • I added a preAction hook which is when we call initAztecJs, a new method which triggers 1-200ms if initialization in bb.js. This is now also called at start of sandbox. If running in jest, this is automatically called on module load, to save having to mess with a gazillion test files.
• Reworked the bb.js portal workflow so that changes are immediately reflected in yarn-project. We produced a package before as part of build, but meant this step needed to be run after each change. Now the package (what would be published to npm), is just used as part of the Docker build.
• Reworked a bit of how bb.js singleton is initialised and subsequently used.
• Added a ./build-system/start_interactive script, to drop you into a shell with environment configured appropriately for running build-system commands. Useful for debugging rebuild patterns etc. See screenshot.
• As mentioned above, start of a granular 'aztec.js` import api. This provides still provides an abstraction over what our internal module structure is like. We can structure the api however we like, it just provides an alternative to importing everything at once.
• Fixed insufficient signal handling on the sandbox/cli. Sandbox set signal handlers too late meaning the app would only respond to sigint etc if it succesfully reached a certain point. Now installs handlers early, and replaces later for graceful shutdown. (You wouldn't have seen this via yarn as yarn handles signals itself).
• Compile our noir-contracts over all cores, not just 4.

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_history_trial_decrypting_time_in_ms (10): 356 (+53%)

Detailed results

All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.

This benchmark source data is available in JSON format on S3 here.

Values are compared against data from master at commit 63b9cdc5 and shown if the difference exceeds 1%.

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	8 txs	32 txs	128 txs
l1_rollup_calldata_size_in_bytes	45,444	179,588	716,132
l1_rollup_calldata_gas	222,888	868,304	3,448,076
l1_rollup_execution_gas	841,975	3,595,412	22,203,445
l2_block_processing_time_in_ms	2,191 (-1%)	8,483	35,273 (+1%)
note_successful_decrypting_time_in_ms	309 (-3%)	925 (+1%)	3,317 (-1%)
note_trial_decrypting_time_in_ms	18.4 (-27%)	52.5 (+6%)	197 (-3%)
l2_block_building_time_in_ms	20,159	80,444	321,817
l2_block_rollup_simulation_time_in_ms	16,616	66,523	266,041
l2_block_public_tx_process_time_in_ms	3,511 (+1%)	13,841	55,491

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric	5 blocks	10 blocks
node_history_sync_time_in_ms	24,838	47,674
note_history_successful_decrypting_time_in_ms	2,154	4,201 (-1%)
note_history_trial_decrypting_time_in_ms	163 (+1%)	⚠️ 356 (+53%)
node_database_size_in_bytes	3,628,484	3,917,604
pxe_database_size_in_bytes	29,748	59,307

Circuits stats

Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit	circuit_simulation_time_in_ms	circuit_input_size_in_bytes	circuit_output_size_in_bytes
private-kernel-init	199	43,109	20,441
private-kernel-ordering	115	25,833	9,689
base-rollup	2,961	667,692	873
root-rollup	86.3	4,072	881
private-kernel-inner	260	64,516	20,441
public-kernel-private-input	171	25,203	20,441
public-kernel-non-first-iteration	168	25,245	20,441
merge-rollup	10.8	2,592	873

Miscellaneous

Transaction sizes based on how many contracts are deployed in the tx.

Metric	0 deployed contracts	1 deployed contracts
tx_size_in_bytes	10,323	25,938

[PhilWindle]

All looks good to me. Just one comment about what looks like an empty file.

[PhilWindle]

Did you mean to commit this?