search

RazrFalcon / cargo-bloat

Find out what takes most of the space in your executable.
MIT License
2.38k stars 52 forks source link

Analyze .rodata too #66

Open shufps opened 3 years ago

shufps commented 3 years ago

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 :)

RazrFalcon commented 3 years ago

This is planned.

RazrFalcon commented 3 years ago

Ok, so the problem with .rodata is that its content is not defined. Only the app itself during execution knows what data is what. So we cannot "index" it beforehand without relying on disassembling, which is far from trivial.

jplatte commented 2 years ago

Is this where debuginfo is stored? I just cut down a test binary's size from ~450MB to ~60MB by setting profile.dev.debug = 0 in Cargo.toml, would have been nice if cargo bloat had told me before that it was such a huge part of the binary.

glandium commented 2 years ago

FWIW, with --symbols-section .rodata and a patch to binfarce for it not to filter out STT_FUNC symbols in https://github.com/Shnatsel/binfarce/blob/ff619127bd1400d3589fec0ff067b4edb3b45d9c/src/elf64.rs#L247-L252, you can get useful results, like in https://github.com/unicode-rs/unicode-normalization/pull/86#issuecomment-1164910121

RazrFalcon commented 2 years ago

@glandium are you sure this is enough? It might help a bit in case of ELF, but still not a general solution.

glandium commented 2 years ago

It's not enough, but it's already helpful. I've seen cases where [unknown] stays high, though.