So I’m trying to run tests from within a canister, and I don’t want to run into cycle limits per query or update call (message), so I am attempting to use the emulator. It is extremely slow, running only a handful of tests in 5 minutes, whereas with the local replica I can run 1000s or tests within the same amount of time (perhaps 10,000s).
Is there some obvious limitation of the emulator that I am missing? And again, being able to configure the cycle limits for the local replica would be really nice
1 Like
The emulator is a lightweight, reference implementation of the IC (with no concensus) but employs a very naive reference implementation wasm interpreter for executing webassembly. So latency due to messaging is low, but the cost of actual wasm computation is high. That (or a bug) might explain the difference.
@dsarlis, @roman-kashitsyn are you aware of any way to override the cycle limit for a local replica?
1 Like
I’ve enquired internally and these limits remain hard-coded into the replica and would need a custom build of (modified) replica sources.
1 Like
Is it technically/legally (thinking of licensing) possible for me to create my own replica build?
Basically the cycle limit will keep me at 100s of test iterations (property-based tests with random inputs) versus possibly 1,000,000s. The latter would be easy if I could just remove the cycle limit, would be a bit of a pain to try to configure my tests to work around the limit.
See https://dfinity.org/licenses/IC-shared-1.0/. Note the clause “The licenses granted in sections 2(A) and 2(B) extend only to the software or derivative works that you create that run directly on the Internet Computer platform or the Ethereum network.”
However, I’m not sure if the license stops you from building a replica for your own use or just distributing it (I have not read it myself).
GitHub - dfinity/ic: Internet Computer blockchain source: the client/replica software run by nodes</ti has instructions for building a replica in a docker image. I’m told that
file rs/config/src/subnet_config.rs has the relevant constants.
However, I expect this approach will be more of a time sink than just arranging to run your tests in batches somehow.
Isn’t the cycle limit a configuration option? At least it was at some time, and for drun it could be set via the configuration file. But maybe that has changed, and also passing a configuration file to a local replica might be tricky.
Actually, ‘replica - -simple-config’ does list it, and ‘.dfx’ folders in project seem to configure other replica options, so might be worth a hack.
(But I was assured by a replica team member it was a compile time const.)