cargo-bloat

Find out what takes most of the space in your executable.

Explore on GitHub Read Hacker News discussions

2Distinct people

2Mentions

0Explicit recommenders

2.8KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Find out what takes most of the space in your executable.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year2 dated mentions

Observed mentions: 2018-04-02 15:35:34 UTC to 2025-01-19 11:33:14 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1

What Hacker News says

2 sources

erebe__·Jan 19, 2025

Hello, You can see my other comment https://news.ycombinator.com/item?id=42708904#42756072 for more details. But yes, the cache does persist after the first call, the resolved symbols stay in the cache to speed up the resolution of next calls. Regarding the why, it is mainly because 1. this app is a gRPC server and contains a lot of generated code (you can investigate binary bloat with rust with https://github.com/RazrFalcon/cargo-bloat) 2. and that we ship our binary with debug symbols, with those options ``` ENV RUSTFLAGS="-C link-arg=-Wl,--compress-debug-sections=zlib -C force-frame-pointers=yes" ``` For the panic, indeed, I had the same question on Reddit. For this particular service, we don't expect panics at all, it is just that by default we ship all our rust binaries with backtrace enabled. And we have added an extra api endpoint

Read the rest

to trigger a catched panic on purpose for other apps to be sure our sizing is correct.

In Rust: Investigating an Out of Memory Error

zokier·Apr 2, 2018

While not answering the question directly, you can peek into Cargo.lock to see what all libraries are used by the project: https://github.com/spacekookie/tinyrocket/blob/master/Cargo.... Of course what of those end up in the final binary is an open question. It would be kinda cool to see a dependency tree with size annotations, but I suppose that might be bit tricky to produce. But I did find "cargo-bloat"[1] tool that gives following output: File .text Size Name 4.8% 19.5% 98.2KiB core 4.0% 16.3% 81.9KiB std 3.9% 15.8% 79.4KiB rocket 2.4% 9.9% 49.9KiB hyper 2.0% 8.1% 40.6KiB [Unknown] 1.7% 7.0% 35.3KiB alloc 1.6% 6.5% 32.7KiB toml 1.1% 4.5% 22.5KiB url 1.0% 4.3% 21.4KiB yansi 0.5% 2.0% 9.9KiB tinyrocket 0.5% 1.8% 9.2KiB time 0.3% 1.3%

Read the rest

6.4KiB ring 0.2% 0.8% 3.8KiB ordermap 0.1% 0.5% 2.4KiB idna 0.1% 0.4% 1.8KiB percent_encoding 0.1% 0.4% 1.8KiB unicode_normalization 0.1% 0.3% 1.3KiB serde 0.1% 0.2% 1.2KiB std_unicode 0.0% 0.2% 880B pear 0.0% 0.1% 576B log 0.0% 0.1% 338B cookie 0.0% 0.1% 307B unwind 0.0% 0.0% 198B unicode_bidi 0.0% 0.0% 161B state 0.0% 0.0% 160B httparse 0.0% 0.0% 124B memchr 0.0% 0.0% 94B alloc_system 0.0% 0.0% 77B typeable 0.0% 0.0% 52B smallvec 0.0% 0.0% 45B compiler_builtins 0.0% 0.0% 28B rustc_tsan 0.0% 0.0% 25B unicase 0.0% 0.0% 11B panic_abort 0.0% 0.0% 11B panic_unwind 24.6% 100.0% 502.6KiB .text section size, the file size is 2.0MiB When the stripped binary on my system is 979K. So it manages to account for about half of the binary size. From what is accounted, I suppose yansi (ANSI terminal lib) is the most superfluous, followed by toml parsing. Other than those, most of the stuff seems kinda relevant for a web framework. I'm now bit curious what the 979 - 502.6 = 476.4 remaining kilobytes are.. and totally nerdsniped. Running size gets me following: [zokier@zarch tinyrocket]$ size -A -d target/release/tinyrocket target/release/tinyrocket : section size addr .interp 28 624 .note.ABI-tag 32 652 .note.gnu.build-id 36 684 .gnu.hash 28 720 .dynsym 2568 752 .dynstr 1532 3320 .gnu.version 214 4852 .gnu.version_r 288 5072 .rela.dyn 40320 5360 .rela.plt 2328 45680 .init 23 48008 .plt 1568 48032 .plt.got 8 49600 .text 519185 49664 .fini 9 568852 .rodata 294652 568864 .eh_frame_hdr 15580 863516 .eh_frame 82544 879096 .tdata 48 3060064 .tbss 136 3060112 .init_array 8 3060112 .fini_array 8 3060120 .data.rel.ro 34984 3060128 .dynamic 576 3095112 .got 872 3095688 .data 201 3096576 .bss 464 3096784 .comment 69 0 Total 998309 So almost 290k in .rodata, that seems suspicious. Quick look at it shows about 17k of html as steveklabnik mentioned, but other than that I can't really identify any major blocks. I suppose this is the end of the dive, unless someone knows some tools to get more insight into .rodata data. I suppose in theory it should be possible to track down where in the code each bit of .rodata is accessed from, but that seems bit of a stretch. [1] https://github.com/RazrFalcon/cargo-bloat

In Building Tiny Rust Binaries for Embedded Linux