[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.