You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have no good way to quantitatively track whether a PR will cause a regression in compilation time for important user circuits. A recent example of this coming back to bite us is in the bloblib circuits where compilation times jumped from 10 to 90mins.
Similar to run-external-checks, we should add a workflow to CI which will compile a number of protocol circuits (the rollup circuits in particular) and measure the time taken to do so. This can then:
Define a hard limit on compilation times which will automatically block the PR if exceeded.
As a first cut we can just use time nargo compile --force to extract the compilation time so this is just a devops issue and shouldn't need modifying the compiler.
The text was updated successfully, but these errors were encountered:
If we're compiling many protocol circuits as part of CI we may want to split this over multiple runners and then merge the reports together after the fact. This can be done later though to avoid premature optimization.
We currently have no good way to quantitatively track whether a PR will cause a regression in compilation time for important user circuits. A recent example of this coming back to bite us is in the bloblib circuits where compilation times jumped from 10 to 90mins.
Similar to
run-external-checks
, we should add a workflow to CI which will compile a number of protocol circuits (the rollup circuits in particular) and measure the time taken to do so. This can then:As a first cut we can just use
time nargo compile --force
to extract the compilation time so this is just a devops issue and shouldn't need modifying the compiler.The text was updated successfully, but these errors were encountered: