chore(ci): Active rollup circuits in compilation report

[vezenovm]

Description

Problem*

Started as investigations into #6750 (comment), but looks like the memory issues have been resolved by recent updates. Specifically this switch to u32 for Id #6807.

Summary*

Simply activates the two commented out rollup circuits.

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 29f15a65e4b1db298d998b56efc113d03f4af751, compared to commit: bc03152366f242a6976f6e006e12520989e5e112

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
sha256_regression	-3 ✅	-0.04%
poseidonsponge_x5_254	-3 ✅	-0.07%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
sha256_regression	6,917 (-3)	-0.04%
poseidonsponge_x5_254	4,251 (-3)	-0.07%

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: 29f15a65e4b1db298d998b56efc113d03f4af751, compared to commit: bc03152366f242a6976f6e006e12520989e5e112

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
poseidonsponge_x5_254	+3 ❌	+0.00%
sha256_regression	-3 ✅	-0.00%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
poseidonsponge_x5_254	183,753 (+3)	+0.00%
sha256_regression	118,704 (-3)	-0.00%

[github-actions]

Compilation Sample

Program	Compilation Time
sha256_regression	0m1.396s
regression_4709	0m0.748s
ram_blowup_regression	0m15.929s
rollup-base-public	6m31.974s
rollup-base-private	3m15.731s
private-kernel-tail	0m1.137s
private-kernel-reset	0m9.317s
private-kernel-inner	0m2.405s
parity-root	0m0.834s
noir-contracts	2m39.175s

[TomAFrench]

We don't have a workspace Nargo.toml by default in aztec-packages. This needs to be generated by the generate_variants.js script.

[TomAFrench]

See https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-protocol-circuits

[github-actions]

Peak Memory Sample

Program	Peak Memory
keccak256	78.71M
workspace	121.99M
regression_4709	286.66M
ram_blowup_regression	1.62G
private-kernel-tail	209.11M
private-kernel-reset	848.11M
private-kernel-inner	304.33M
parity-root	174.64M

[vezenovm]

We don't have a workspace Nargo.toml by default in aztec-packages. This needs to be generated by the generate_variants.js script.

Ah yes I forgot about this

[TomAFrench]

tbh, I don't see the logic in running the workspace as we're going to end up with more memory usage on a single runner surely?

[TomAFrench]

Also all the tests are in the lib packages so we can just provide our own workspace file which just includes the library packages if necessary.

[TomAFrench]

I think that using the action may conflict with our cache of node modules

[vezenovm]

tbh, I don't see the logic in running the workspace as we're going to end up with more memory usage on a single runner surely?

I had started on this as I was getting issues in the past when trying to run nargo inside of one of the protocol circuits. I had missed this PR though (#6752), so yeah I agree it probably unnecessary extra work.

[vezenovm]

I'm going to keep this open but just for investigating #6750 (comment)

[vezenovm]

rollup-base-public 6m5.361s
rollup-base-private 3m42.685s

These did not time out as expected

[vezenovm]

Those circuits must have been using too much memory previously and been messing with the runner. Memory should be largely improved after changes like this one #6807, thus we can run these reports again.

[TomAFrench]

Do the rollup circuits still compile when using heaptrack? If so we should add them to the memory tracking Ci as well.

[vezenovm]

Do the rollup circuits still compile when using heaptrack? If so we should add them to the memory tracking Ci as well.

I did not try on the CI as the noir-contracts still do not compile when using heaptrack in the CI and they take ~2m40s vs. 3m and 6m for the rollup circuits. Generally it looks like heaptrack takes 10x as long as normal execution.

I did compile the rollup-base-private locally with heaptrack and got 24G.