Very huge binary

1

Why so huge ~2.5G unstripped binary was generated after ordinary cargo build of ~10.5K Rust code?

➜ ccs ✗ ls -l ./target/debug/ccs
-rwxrwxr-x 2 vit vit 2487901472 Sep 8 15:16 ./target/debug/ccs
➜ ccs ✗ strip ./target/debug/ccs
➜ ccs ✗ ls -l ./target/debug/ccs
-rwxrwxr-x 2 vit vit 22033432 Sep 8 15:31 ./target/debug/ccs
➜ ccs ✗ rustc --version --verbose
rustc 1.71.1 (eb26296b5 2023-08-03)
binary: rustc
commit-hash: eb26296b556cef10fb713a38f3d16b9886080f26
commit-date: 2023-08-03
host: x86_64-unknown-linux-gnu
release: 1.71.1
LLVM version: 16.0.5
➜ ccs ✗
2

What size is it when compiling in release mode? Is it pulling in any large dependencies (showing the Cargo.toml might be helpful)?

3

In the default debug mode Rust intentionally makes very large bloated binaries — it adds lots of debug info, generates unoptimized code, and does not remove any redundant or unused code. Additionally, it works inefficiently, because it tries to work quickly.

If you care about binary sizes, you have to enable optimizations, and strip debug info.

5 Likes
4

In release mode, the size is quite adequate:

➜  ccs ✗ cargo build --release
~...~
➜  ccs ✗ ls -l ./target/debug/ccs
-rwxrwxr-x 2 vit vit 22033432 Sep  8 15:31 ./target/debug/ccs
➜  ccs ✗

Dependencies list:

[dependencies]
toml = "0.7.5"
pretty_env_logger = "0.5.0"
log = "0.4.19"
env_logger = "0.10.0"
r2d2 = "0.8.10"
diesel = { version = "1.4.8", default-features = false, features = [ "sqlite", "r2d2", "32-column-tables", "numeric", "chrono" ] }
serde = { version="1.0.164", features=['derive'] }
serde_derive = "1.0.164"
serde_json = "1.0.99"
futures = "0.3.28"
tokio = { version = "1.29.1", features = ["time", "macros", "rt-multi-thread"] }
tokio-stream = "0.1.14"
warp = "0.3.5"
failure = "0.1.8"
nuid = "0.4.1"
chrono = { version = "0.4.26", features = ["serde"] }
urlencoding = "2.1.2"
once_cell = "1.18.0"
utoipa = { version = "3.3.0", features = ["preserve_order"] }
utoipa-swagger-ui = "3.1.3"
http = "0.2.9"
argh = "0.1.10"
crossbeam = "0.8.2"
5

With serde_derive and without optimizations it is easy to achieve unreasonable binary size and slow compilation. You can use cargo-bloat to see what exactly takes space.

1 Like
6

Release builds are saved to target/release, so you should check size for target/release/ccs.

7

Right, tnx, we can compare both stripped bins:

➜  ccs ✗ ls -l ./target/{debug,release}/ccs
-rwxrwxr-x 2 vit vit 22033432 Sep  8 15:31 ./target/debug/ccs
-rwxrwxr-x 2 vit vit  4870568 Sep  8 16:51 ./target/release/ccs
➜  ccs ✗
8

Result of cargo-bloat is below:

➜  ccs ✗ cargo bloat --crates --full-fn
~...~
    Analyzing target/debug/ccs

File  .text     Size Crate
0.1%  20.4%   3.3MiB core
0.1%  17.0%   2.7MiB warp
0.1%   8.6%   1.4MiB diesel
0.1%   8.2%   1.3MiB h2
0.0%   5.8% 946.3KiB regex_automata
0.0%   5.1% 834.2KiB toml_edit
0.0%   4.5% 739.8KiB hyper
0.0%   4.3% 702.9KiB aho_corasick
0.0%   4.0% 650.7KiB tokio
0.0%   3.5% 578.3KiB regex_syntax
0.0%   3.5% 568.0KiB std
0.0%   1.7% 282.5KiB serde_json
0.0%   1.2% 192.2KiB rand_chacha
0.0%   0.9% 140.2KiB http
0.0%   0.8% 137.1KiB memchr
0.0%   0.7% 111.5KiB env_logger
0.0%   0.4%  70.0KiB num_cpus
0.0%   0.4%  66.3KiB bytes
0.0%   0.4%  59.2KiB serde
0.0%   0.4%  57.6KiB futures_util
0.0%   5.7% 934.0KiB And 78 more crates. Use -n N to show more.
0.7% 100.0%  16.0MiB .text section size, the file size is 2392.3MiB

Note: numbers above are a result of guesswork. They are not 100% correct and never will be.
➜  ccs ✗
9

Note that cargo bloat also needs the --release flag.

10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.