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
This project is currently in the structure of a gigantic library plus a few manage commands.
The issue is that the binaries are very fat and having multiple of them eats up disk space quickly. libcargo_registry on debug build takes over 100MB on its own, and it's linked to 8 different binaries. My target directory is easily over 2GB.
Also, this approach is no good for deployment as well. It leads to larger uploaded bundle, although gzip should help here.
Instead, we should have one monolithic binary and handle all the subcommands with clap. As a random note, Clap 3.x in development allows more modular code because it removes the facade between App and Subcommand.
The text was updated successfully, but these errors were encountered:
I think consolidating into two binaries (maybe server and ops) would be a good goal, though we can make incremental progress by combining just a few binaries at a time.
Right now, when running cargo test: lib.rs, all binaries, and all.rs are built in both debug and test profiles. (Cargo assumes that tests may exec any binary, so regular binaries are build in addition to the test binaries.) None of our binaries include tests so this is a lot of extra build time that doesn't add useful feedback to the development cycle.
Even when linking with lld via RUSTFLAGS="-C link-arg=-fuse-ld=lld", all this extra linking adds to the build time.
By consolidating into fewer binaries, it should improve build time and RAM consumption during local development.
This project is currently in the structure of a gigantic library plus a few manage commands.
The issue is that the binaries are very fat and having multiple of them eats up disk space quickly.
libcargo_registry
on debug build takes over 100MB on its own, and it's linked to 8 different binaries. My target directory is easily over 2GB.Also, this approach is no good for deployment as well. It leads to larger uploaded bundle, although gzip should help here.
Instead, we should have one monolithic binary and handle all the subcommands with clap. As a random note, Clap 3.x in development allows more modular code because it removes the facade between App and Subcommand.
The text was updated successfully, but these errors were encountered: