Closed andqk00 closed 1 year ago
Which version are you using?
Are you compiling on the native CPU type? I.e. use cosmwasm/workspace-optimizer for x86_64 and cosmwasm/workspace-optimizer-arm64 for ARM machines?
Any updates here?
Which version are you using?
Are you compiling on the native CPU type? I.e. use cosmwasm/workspace-optimizer for x86_64 and cosmwasm/workspace-optimizer-arm64 for ARM machines?
oops sorry I totally forgot after posting the issue. Yes I'm using the correct image for my OS. And it happens for pretty much all the versions.
What does "took too long" mean? At which point does it break?
Did you try the latest 0.12.13? This enables Cargo's sparse protocol which makes loading the crates.io index significantly faster. It might explain the difference between local an remote because locally you can use some cache.
How large is the codebase? How long does a local recompile take?
I also use a volume to cache the crates.io on remote but that makes no different. After inspecting the log I found out that it is the compile step that takes up time but not the downloading crates step.
Normally in local it takes ~10mins to compile a cw-nfts or cw-plus workspace contract but on remote it usually takes >30mins to compile the same source code. And it often gets stuck at the compile step, like it is compiling a few packages and then it stopped for like a minute or so and then it continue to compile the next one, and that repeats for several times until the compile process complete.
I know nothing about Kubernetes and stuff but it sounds like you have some restricted resources there.
How is your memory usage? Is the process swapping to disk? Is it compiling on multiple cores?
Usually it will takes up ~1.5 gb when compiling a source code. In K8s, the CPU and memory can increase to meet the needs of services so I don't think that's the problem.
Anyway, I was just suggesting if there is a way I can specify the contract to compile in a workspace source code while using the workspace-optimizer image, that might reduce the compile time significantly.
Maybe it is also a matter of expectations. Are you building the Wasm file on every commit? I think best practice is to only compile them for releases.
In some other project we use this script to build local Wasm files. This is much faster than going through workspace-optimizer but not suiteable for reproducible builds and verification.
Acrually I was building a service to verify the contract source code, and using this image to compile that source code.
Are you aware of this build cache? --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target
. This creates a volume called e.g. cw-nfts_cache
which you should see in Docker. Maybe this is the reason it runs faster locally. What happens if you remove it and do a fresh compilation?
specify the contract to compile in a workspace source code while using the workspace-optimizer image, that might reduce the compile time significantly
This creates the issue of requiring more parameters for the verification which we want to avoid. Source + builder (Docker image + tag) should be sufficient. Also a lot of the time usually goes into compiiling the dependencies of the workspace which you do once for all contracts.
Yup got it. Cheers.
Hi team, I am facing an issue where a workspace contract took too long to compile on Kubernetes comparing to when I run it local. I don't know what is the root cause of this issue, but I think one way to work around this is to have a way to define the contract that needs to compile in the workspace, so that the image only compile that contract rather than the hold contracts in workspace.