Run on Library Crates

[sunjay]

Thanks for creating this tool! 😄

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.

[RazrFalcon]

Is there a way to run cargo bloat on crates that are just libraries?

No, because executables and libraries are very different. Especially static libraries, which is the default.

Examples support is a good idea, but note that cargo-bloat will show only stuff that is used by example, so you have to use as many features of your library as possible.

[sunjay]

Examples support is a good idea, but note that cargo-bloat will show only stuff that is used by example, so you have to use as many features of your library as possible.

That would be fine. I think having that much support would still be extremely helpful. :)

[CryZe]

I'm compiling my code to a static & dynamic library, so extending it to work on those cases would be really cool too.

[RazrFalcon]

@CryZe it's not possible due to the way executables and libraries are work. You can measure only executables.

[CryZe]

Can you elaborate why?

[RazrFalcon]

I'm not that good in this, but the basics look like this:

• The static library is just a pile of code (in c/c++/rust it's an actual archive file with objects and some metadata). No optimizations are made afaik.
• The dynamic library is something in between. It support optimization, but not LTO afaik.
• The executable file format usually has the .text section in which the compiled code contains. And all this tool doing is measuring so-called symbols size. You can call them functions or methods. But Rust (and C++) has two other problems:
  • Generics (hello Go). The library can define generics, but not use them by itself, so they will be instanced only in the executable, so you can't measure them in the library.
  • Inlining. Rust supports inlining which eliminates some functions completely. But there is no inlining in the static libraries (afaik) and only to some extend in dynamic library, so the results will be different.

[RazrFalcon]

Done.

[sunjay]

Thank you! :)

[kupiakos]

Any chance we can reconsider this for staticlib? Bloaty supports them, so it's definitely possible in theory.

[RazrFalcon]

There is nothing interesting in staticlib and it doesn't affect the final binary in any way.
Remember, that staticlib is just an archive of an intermediate compiler output. It still has to be compiled.

[kupiakos]

There is interesting info in a staticlib, especially for embedded use cases that don't load in a traditional manner. A staticlib is a collection of .o files - it is compiled, just not linked yet. It's not an rlib. While the output is imperfect (no LTO, for example), it's still useful data.
Bloaty supports analyzing a .a/static lib because it can still provide useful information. You are incorrect about there being nothing interesting.

[RazrFalcon]

I will rephrase: it's not interested for cargo-bloat use case. cargo-bloat analyzes final binaries. That's it.

[kupiakos]

Why? I was planning on implementing this support, and would really rather not maintain a project fork for a feature that I believe should be there in the first place. Right now we have to settle with Bloaty, which doesn't yet have Rust name demangling.

[RazrFalcon]

Because cargo-bloat prints .text section output. Can we get anything like this from static lib? I don't think so.
Can you show bloaty output?