[FEATURE] gate count profiling can be at compile time instead of at runtime

[shiqicao]

Problem Statement

Following https://docs.aztec.network/developers/docs/aztec-nr/framework-description/advanced/how_to_profile_transactions, if I need to know gate count of a contract, I have to setup an env to almost run it, which dramatically slows develop productivity.

"Profile with aztec-wallet" doesn't work for us, because we are using a different account contract.

Gate count should be available after compiling.

Proposed Solution

Looking forward to a solution to avoid requiring js code

Example Use Case

No response

Alternative Solutions

No response

Additional Context

No response

[wei3erHase]

i'm not sure i follow, gate count is available (using flamegraph for example) as soon as you compile the contract (they're static), tho they are per-method, and if the execution requires to call another contract you won't see it, the real gate-count of the full tx requires to simulate it (which requires to setup the env), consider that this simulation also adds your account contract and all the intermediary kernel iterations of doing external calls

[wei3erHase]

example of compile vs runtime:
in Aztec Token (for test), a user is able to send up to 16 Balance Notes, if it's not enough to cover the full transfer amount, the contract will call itself recursively until it reaches the full balance (if there enough Notes, ofc)

at compilation time, the gate-count will reflect the 16 Balance Notes, and the if saying that it could call itself, but you won't see the recursive calls
at runtime, the actual gate-count will depend on the execution, if 1 Note covers the balance, it'll be exactly as the compilation time gate-count, but if you need 17 Notes, it'll do the recursive call, and add the 100k gates of kernel iteration + the recursive call logic to the gate-count

[nventuro]

@shiqicao to clarify, are you trying to profile a sample transaction, or to see the gatecounts of the different #[external(private)] functions? As @wei3erHase noted above, these have different meanings and are quite different to obtain.

If the latter (just gate counts for the private functions), do you want a detailed understanding of where the gate count comes from (like a flamegraph), or just the total number?

[shiqicao]

@wei3erHase I need to have both compile time / run time gate count, compile time gate count is helpful during inner loop development, whereas run time gate count is more like integration test.

@nventuro , following "Generate flamegraphs with noir-profiler", I got Error reading program from file: Failed to deserialize artifact from JSON: expected a program artifact but found a contract in ...

[nventuro]

We could either add flags to compile to summarize the gate counts, or replace the flamegraph with aztec profile with options etc to do this, as well as making sure it's up to date and works. I'm not so sure about runtime profiling - I'd first focus on getting this stable and then look into that.

[shiqicao]

Runtime profiling works as documented

[nchamo]

Hey @shiqicao and @wei3erHase !

Just wanted to get some feedback from you. My current plan is to add a new aztec profile command where we add these types of things.
I would start with aztec profile gates where something like this:

Would generate an output like this:

Then, I can work on moving the logic on aztec flamegraph to aztec profile flamegraph (or something like that)

What do you think?

[nchamo]

Adding @ludamad 's feedback here:

Hi hmm we intentionally did not make aztec profile in the past as aztec simulate does this

[nchamo]

Hey @ludamad! Please correct me if I'm wrong but, based on the code, I think aztec-wallet simulate will never actually return the gates count. But even if it did, wouldn't that be the run time count vs compile time discussed on this issue?

[ludamad]

No it'll print gate counts too. but wait - in this case, bb gates is surely the tool? you can just compile your circuit and find out the number of gates. That is the noir backend, it should be it's concern no?

[ludamad]

Why would we need the aztec node at all for this low level ask?

[nchamo]

We discussed it offline, all good 👍