chore: Do not rebuild yarn-projects on bench-comment

[spalladino]

The bench-comment job was re-running bootstrap.sh on yarn-project (see here, most likely because the "Download base benchmark" step on ci.yml was downloading a new file to yarn-projects, which caused the COPY . . in yarn project build to miss cache.

This downloads the bench files outside the source folder, so it doesn't trigger a rebuild.

[github-actions]

Changes to circuit sizes

Generated at commit: 070fc84fc4a52389988db69388db489aedb23a56, compared to commit: 5c733d1fc9152317a89731793896487a5c72cc30

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_reset	0 ➖	0.00%	+3,008 ❌	+0.12%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_reset	249,630 (0)	0.00%	2,488,705 (+3,008)	+0.12%

[AztecBot]

Benchmark results

No base data found for comparison.

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.

L2 block published to L1

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

Metric	8 txs	32 txs	64 txs
l1_rollup_calldata_size_in_bytes	740	740	740
l1_rollup_calldata_gas	6,668	6,692	6,680
l1_rollup_execution_gas	586,853	586,877	586,865
l2_block_processing_time_in_ms	1,611	6,036	12,072
l2_block_building_time_in_ms	35,430	138,452	275,539
l2_block_rollup_simulation_time_in_ms	35,207	137,668	273,942
l2_block_public_tx_process_time_in_ms	16,587	70,451	141,813

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	17,936	33,307
node_database_size_in_bytes	21,377,104	38,232,144
pxe_database_size_in_bytes	29,868	59,425

Circuits stats

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

Circuit	protocol_circuit_simulation_time_in_ms	protocol_circuit_witness_generation_time_in_ms	protocol_circuit_proving_time_in_ms	protocol_circuit_input_size_in_bytes	protocol_circuit_output_size_in_bytes	protocol_circuit_proof_size_in_bytes	protocol_circuit_num_public_inputs	protocol_circuit_size_in_gates
private-kernel-init	161	3,607	22,723	20,370	61,703	85,376	2,601	1,048,576
private-kernel-inner	524	4,629	44,911	88,991	61,561	85,376	2,601	2,097,152
private-kernel-reset	973	6,374	87,415	326,234	61,703	85,376	2,601	4,194,304
private-kernel-tail	528	4,854	38,080	87,224	79,333	10,656	266	2,097,152
base-parity	8.71	325	8,523	128	64.0	2,208	2.00	131,072
root-parity	51.5	188	98,139	27,064	64.0	2,720	18.0	2,097,152
base-rollup	913	7,237	92,226	111,126	925	3,104	30.0	2,097,152
root-rollup	72.8	187	11,936	11,454	789	3,424	40.0	524,288
public-kernel-app-logic	190	329	534	96,439	84,663	99,596	3,475	4,096
public-kernel-tail	870	656	732	380,923	7,723	10,144	250	512
public-kernel-setup	146	343	641	115,582	79,079	99,244	3,475	4,096
public-kernel-teardown	154	415	750	123,661	80,340	101,888	3,475	4,096
private-kernel-ordering	445	N/A	N/A	70,968	45,252	N/A	N/A	N/A
merge-rollup	6.71	110	2,280	2,696	925	3,104	30.0	65,536
private-kernel-tail-to-public	N/A	10,083	68,472	N/A	N/A	113,856	3,491	4,194,304

Stats on running time collected for app circuits

Function	app_circuit_proof_size_in_bytes	app_circuit_proving_time_in_ms	app_circuit_size_in_gates	app_circuit_num_public_inputs
SchnorrAccount:entrypoint	15,456	47,379	2,097,152	416
Test:emit_nullifier	15,456	2,323	65,536	416
FPC:fee_entrypoint_public	15,456	8,656	524,288	416
Token:transfer	15,456	39,513	2,097,152	416
FPC:fee_entrypoint_private	15,456	8,925	524,288	416
Token:unshield	15,456	36,986	2,097,152	416
SchnorrAccount:spend_private_authwit	15,456	2,663	131,072	416

Tree insertion stats

The duration to insert a fixed batch of leaves into each tree type.

Metric	1 leaves	16 leaves	64 leaves	128 leaves	512 leaves	1024 leaves	2048 leaves	4096 leaves	32 leaves
batch_insert_into_append_only_tree_16_depth_ms	13.2	21.4	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.7	31.8	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.770	0.659	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	61.7	96.8	315	606	1,191	2,366	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	159	543	1,055	2,079	4,127	N/A
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	0.634	0.599	0.572	0.568	0.565	0.565	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	74.2	143	455	889	1,770	3,542	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	106	208	692	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.645	0.643	0.619	0.614	0.613	0.616	N/A
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	80.9
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	109
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	0.709

Miscellaneous

Transaction sizes based on how many contract classes are registered in the tx.

Metric	0 registered classes	1 registered classes
tx_size_in_bytes	83,545	766,808

Transaction size based on fee payment method

| Metric | |
| - | |

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes	2 new note hashes
tx_pxe_processing_time_ms	26,142	3,618	113,350

Metric	0 public data writes	1 public data writes	2 public data writes	4 public data writes	8 public data writes
tx_sequencer_processing_time_ms	1,065	2,249	1,681	2,637	1,668

[TomAFrench]

Is this good to merge? This has been causing some pain on my side where the logs are all there but I need to wait ages for them to be aggregated/displayed (compounded by locks from other PRs preventing the build from starting)

[spalladino]

I was going to say that no, because it was still rebuilding everything, but I now see that bench-summary indeed used the cached build in a more recent run. So I guess we're good? Let's give it a shot.