See https://github.com/RazrFalcon/cargo-bloat/issues/17, I think this may be ready to merge as-is but it seems to be missing quite a few symbols. Not sure if merging initial support and possible improvements later is preferred, or waiting to see if we can get a better implementation.

Example output on this crate:

D:\dev\cargo-bloat [master ↑2]> cargo run ; cargo run --release -- --release
   Compiling cargo-bloat v0.10.1 (D:\dev\cargo-bloat)
    Finished dev [unoptimized + debuginfo] target(s) in 1.27s
     Running `target\debug\cargo-bloat.exe`
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
    Analyzing target\debug\cargo-bloat.exe

 File  .text    Size         Crate Name
 1.1%   1.4% 28.1KiB          json json::parser::Parser::parse
 0.5%   0.7% 13.2KiB          json json::util::print_dec::write
 0.5%   0.6% 11.8KiB  cargo_bloat? cargo_bloat::process_crate
 0.5%   0.6% 11.7KiB          json json::codegen::Generator::write_json
 0.5%   0.6% 11.6KiB          std? std::sys::windows::process::Command::spawn
 0.5%   0.6% 11.6KiB  cargo_bloat? cargo_bloat::parse_args
 0.4%   0.5% 10.6KiB  cargo_bloat? cargo_bloat::collect_pe_data
 0.3%   0.4%  8.0KiB           pdb <pdb::symbol::SymbolData as scroll::ctx::TryFromCtx>::try_from_ctx
 0.3%   0.4%  7.0KiB  regex_syntax <regex_syntax::hir::translate::TranslatorI as regex_syntax::ast::visitor::Visitor>::visit_class_set_item_post
 0.3%   0.3%  6.8KiB regex_syntax? regex_syntax::ast::parse::ParserI<ref_mut$<regex_syntax::ast::parse::Parser> >::parse_with_comments<ref_mut$<regex_syntax::ast::parse::Parser> >
 0.3%   0.3%  6.6KiB  regex_syntax <regex_syntax::hir::translate::TranslatorI as regex_syntax::ast::visitor::Visitor>::visit_post
 0.2%   0.3%  5.3KiB          std? alloc::collections::btree::map::BTreeMap::insert<std::sys::windows::process::EnvKey,std::ffi::os_str::OsString>
 0.2%   0.3%  5.3KiB         regex regex::exec::ExecBuilder::build
 0.2%   0.3%  5.3KiB           std core::num::flt2dec::strategy::dragon::format_shortest
 0.2%   0.3%  5.3KiB          std? alloc::collections::btree::map::BTreeMap::insert<std::sys::windows::process::EnvKey,enum$<core::option::Option<std::ffi::os_str::OsString>, 1, 1844674...
 0.2%   0.2%  4.7KiB  regex_syntax alloc::str::join_generic_copy
 0.2%   0.2%  4.5KiB      binfarce <binfarce::demangle::legacy::Demangle as core::fmt::Display>::fmt
 0.2%   0.2%  4.4KiB  cargo_bloat? cargo_bloat::main
 0.2%   0.2%  4.4KiB      binfarce binfarce::pe::Pe::symbols
 0.2%   0.2%  4.4KiB           std core::num::flt2dec::strategy::dragon::format_exact
69.2%  86.9%  1.7MiB               And 10270 smaller methods. Use -n N to show more.
79.6% 100.0%  1.9MiB               .text section size, the file size is 2.4MiB
   Compiling cargo-bloat v0.10.1 (D:\dev\cargo-bloat)
    Finished release [optimized] target(s) in 4.32s
     Running `target\release\cargo-bloat.exe --release`
    Finished release [optimized] target(s) in 0.02s
    Analyzing target\release\cargo-bloat.exe

 File  .text     Size Crate Name
 1.2%   1.6%  11.6KiB  std? std::sys::windows::process::Command::spawn
 0.6%   0.7%   5.3KiB  std? alloc::collections::btree::map::BTreeMap::insert<std::sys::windows::process::EnvKey,std::ffi::os_str::OsString>
 0.6%   0.7%   5.3KiB   std core::num::flt2dec::strategy::dragon::format_shortest
 0.6%   0.7%   5.3KiB  std? alloc::collections::btree::map::BTreeMap::insert<std::sys::windows::process::EnvKey,enum$<core::option::Option<std::ffi::os_str::OsString>, 1, 18446744073709...
 0.5%   0.6%   4.4KiB   std core::num::flt2dec::strategy::dragon::format_exact
 0.4%   0.5%   3.8KiB  std? rustc_demangle::v0::Printer::print_type
 0.3%   0.4%   3.3KiB   std rustc_demangle::demangle
 0.3%   0.4%   3.2KiB  std? std::sys::windows::process::Stdio::to_handle
 0.3%   0.4%   3.1KiB   std <rustc_demangle::legacy::Demangle as core::fmt::Display>::fmt
 0.3%   0.4%   3.0KiB   std std::process::Child::wait_with_output
 0.3%   0.4%   2.9KiB  std? rustc_demangle::v0::Printer::print_const
 0.3%   0.3%   2.6KiB  std? rustc_demangle::v0::Printer::print_path
 0.3%   0.3%   2.5KiB   std std::env::args_os
 0.2%   0.3%   2.3KiB   std core::num::flt2dec::strategy::grisu::format_shortest_opt
 0.2%   0.3%   2.1KiB  std? std::sys::windows::process::make_command_line::append_arg
 0.2%   0.2%   1.6KiB  std? std::backtrace_rs::print::BacktraceFrameFmt::print_raw_with_column
 0.2%   0.2%   1.6KiB  std? alloc::collections::btree::node::Handle::remove_leaf_kv<std::sys::windows::process::EnvKey,std::ffi::os_str::OsString,alloc::collections::btree::map::entry::...
 0.2%   0.2%   1.5KiB  std? std::panicking::default_hook
 0.2%   0.2%   1.5KiB   std <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
 0.2%   0.2%   1.5KiB  std? rustc_demangle::v0::impl$6::print_type::closure$0
12.6%  16.2% 121.3KiB       And 518 smaller methods. Use -n N to show more.
78.2% 100.0% 751.0KiB       .text section size, the file size is 960.5KiB

git clone https://github.com/qarmin/czkawka
cd czkawka
cargo bloat --release

will print this panic

rafal@rafalDesktop:~/Projekty/Rust/czkawka$ cargo bloat --release
    Finished release [optimized] target(s) in 0.08s
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: MalformedInput', /home/rafal/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-bloat-0.10.0/src/main.rs:806:59
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

how to reproduce, with the example of a fresh git checkout:

cd tmp && git clone https://github.com/eqrion/cbindgen.git
cd cbindgen
cargo bloat 
compiling...
Error: failed to find a dir with std libraries. Expected location: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib.

this is on a x86_64 machine, hence there's /usr/lib64/${RUSTVERSION}/ where rustlib resides. Not sure wether that is excentric behavior from my distro? :-)

Thanks for creating this tool! :smile:

Is there a way to run cargo bloat on crates that are just libraries? If you need an executable to run on, I could pass --example foo to generate an executable for that particular example. I would like to use this on my crates to see if any functions/dependencies are taking up most of the binary generated by anyone using the crate.

I just upgraded from 0.5.1 to 0.5.2 as result of a major upgrade frenzy and not cargo bloat spits out these messages when running for e.g. thumbv6m-none-eabi:

Processing example blinky
   Compiling cortex-m-rt v0.5.3
   Compiling cortex-m v0.5.6
   Compiling stm32f042 v0.6.1
LLVM ERROR: Global variable '__RESET_VECTOR' has an invalid section specifier '.vector_table.reset_vector': mach-o section specifier requires a segment whose length is between 1 and 16 characters.
error: Could not compile `cortex-m-rt`.
warning: build failed, waiting for other jobs to finish...
error: build failed

cargo-bloat only returns the size of the text-section of the binary. It would be more useful to try to figure out the size of a library in the whole binary (or to make it more explicit that it only deals with the text section somehow).

Also, would it be possible to include per-library how big the debug symbols for a particular library are?

Interesting crate! In contrast to what the Readme assumes, it doesn't work on macOS. Curiously, it doesn't really fail, but instead outputs this (for cargo-edit):

  NaN% 0B [10222 Others]
  NaN% 0B _je_tcache_boot
  NaN% 0B _je_tcache_cleanup
  NaN% 0B _je_tcache_create
  NaN% 0B _je_tcache_enabled_cleanup
  NaN% 0B _je_tcache_event_hard
  NaN% 0B _je_tcache_get_hard
  NaN% 0B _je_tcache_stats_merge
  NaN% 0B _je_tcaches_create
  NaN% 0B _je_tcaches_destroy
  NaN% 0B _je_tcaches_flush
  NaN% 0B _je_thread_allocated_cleanup
  NaN% 0B _je_thread_deallocated_cleanup
  NaN% 0B _je_tsd_cleanup
  NaN% 0B _je_tsd_init_check_recursion
  NaN% 0B _je_tsd_init_finish
  NaN% 0B _je_witness_fork_cleanup
  NaN% 0B _je_witnesses_cleanup
  NaN% 0B _main
  NaN% 0B _rust_begin_unwind
  NaN% 0B _rust_eh_personality
100.0% 0B Total

Looks like the object crate just reports 0 bytes all the time? Should it ever return 0?

I've been getting this error recently, and even rebuilding cargo-bloat doesn't fix it. I've also tried clearing target/release/, but the result is the same. Have you seen this before?

Thank you kindly.

Steps to reproduce

1. clone solana repo.
2. run cargo bloat --time

Output

This repo can be builded with cargo build with no errors.

Meanwhile bare cargo bloat works.

Thanks for this awesome tool! I'm building a github action to run cargo bloat on projects. Would you be willing to add support for distributing pre-built binaries via github releases, for environments where a cargo install would be too slow or expensive?

This can be entirely automated with Github actions themselves.

I installed cargo bloat on a Mac and the functionality is great and useful. However, after running cargo bloat --crates --time, I am seeing output like this every time I run any cargo command (build, clippy, etc.):

json-time {"crate_name":"derive_builder_macro","time":1492788223,"build_script":false}
json-time {"crate_name":"git2","time":6255647714,"build_script":false}
json-time {"crate_name":"build_info_proc","time":4735568231,"build_script":false}
json-time {"crate_name":"syntex_syntax","time":25882835499,"build_script":false}
json-time {"crate_name":"tonic_build","time":2963543957,"build_script":false}
json-time {"crate_name":"build_info_build","time":2070763756,"build_script":false}
json-time {"crate_name":"derive_builder","time":536162450,"build_script":false}
json-time {"crate_name":"rustfmt","time":9911235635,"build_script":false}

This happens even after I uninstall cargo bloat, which is very weird, as I see that the output is indeed generated by this script: https://github.com/RazrFalcon/cargo-bloat/blob/master/src/main.rs#L423-L428. I verified that there is no binary named cargo-bloat inside ~/.cargo/bin.

This is driving me a bit crazy, lol. Any cargo experts here can help me figure out why this is happening?

term_size is officially unmaintained and the authors recommend switching to terminal_size [1].

[1] https://github.com/clap-rs/term_size-rs/blob/5889fdc589d267182cc946faa24e0e3166a70000/README.md

cargo +nightly bloat -Z build-std --target x86_64-apple-darwin
Error: failed to find a dir with std libraries. Expected location: /Users/user/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib.

Just a minor nit: if all data is shown, cargo-bloat outputs something like 0.0% 0.0% 0B And 0 smaller methods. Use -n N to show more. which could probably be skipped altogether :)

I noticed cargo bloat report a smaller .text size than GNU binutils size for the same binary (by only a couple KB, but happens to be 10% or so in this case).

Steps to replicate issue documented here, the discrepancy is:

| | cargo bloat | cargo size | | --- | --- | --- | | min_size_no_std | 14.7KB | 17.0KB | | min_size_std | 16.4KB | 17.8KB |

Note cargo size's output is consistent with using the distro-installed size binary from GNU binutils (e.g. size ./target/x86_64-unknown-linux-musl/release/min_size_no_std).

Not sure which tool's output is ground truth, but wanted to bring it to your attention! Thank you for your work on this tool.

I have troubles finding where this insane amount of .rodata is coming from ...

...
.text                 66898   131072
.rodata               33136   197976
...

Would be great, if cargo bloat also could support eg rodata :)