Why is `dfx build` much slower than direct usage of `moc`?

$ time moc --idl --stable-types `mops sources` -o ~/t/test.wasm stress-test/stresser.mo
...
|real|0m33.963s|
|---|---|
|user|0m33.733s|
|sys|0m0.367s|

but

$ time dfx build stresser
...
|real|0m51.280s|
|---|---|
|user|0m52.176s|
|sys|0m2.641s|

stresser canister has no dependencies.

So dfx build is nearly 2 times slower than plain moc invocation. Why? (I suspect that it builds also a wallet canister and is slow because of this.)

This needs to be fixed: dfx build should be faster (or provide flags to make it fast).

I don’t have the full answer since I’m not too familiar with the build process, but I see two invocations of moc in the relevant section of the code base. One call to moc is for actual building, and the other one is to moc --print-deps to figure out which canisters need to be added as dependencies for the actual build command. It makes sense that --print-deps would be faster to invoke, but it still needs to slightly parse everything, so I guess that’s where a solid chunk of the work comes from

While I agree it would be nice to optimize this, I’d rater see something like Rust’s cargo be spliced out of dfx. I don’t like how the two are so tightly tangled. If they’re disconnected I think this would be an easier task to accomplish

Definitely not. dfx build does not touch the wallet canister at all, and it’s pre-built and only needs to be unpacked

1 Like