I’ve gotta be honest… I sorta stopped reading when I got to the part about the library being 1MB. Why would it be important to reduce the size? Maybe on some embedded device with a super-small amount of memory? Otherwise, when your watch has GBs of memory, why optimize for library size?
That aside… cargo bloat seems like a pretty cool tool!
A megabyte here, a megabyte there, soon you have Electron-level bloat, which everyone loves to hate. I don’t know about Federico, but as a library developer, I’m keenly aware that, at least judging by message board discussions, my potential users are harsh critics of bloat. And in my particular case, I don’t want anyone to decide that they’re not going to make their GUI accessible (e.g. to screen reader users) because my library was too bloated.
Your app isn’t alone in your phone. When it grows in size, it will cause other apps to be flushed out of memory, and when backgrounded, it will be flushed out sooner because it occupies memory.
Are you aware of specific parts of std that are bloated due to generics?
I’m not an authority on this, but here’s what I know. The base overhead that std adds to each binary is primarily due to the backtrace functionality. Statically linking the code to walk the stack, read debug info, etc. adds considerable overhead. This code can be removed, but only using the unstable build-std feature of cargo and the unstable panic_immediate_abort feature of std, as documented in min-sized-rust.
I think most people complaining about the size would like to see some way that you can include only the part of the std which your program actually uses. Which IIRC is something we won’t see happening that fast.
It’s already there… With LTO, only the part of std used is included. Two parts of std are problematic for this: one is backtrace, as already mentioned. Another is formatting: it uses dynamic dispatch so unused code may be included due to analysis conservatism. Otherwise, all unused parts of std should be removed by LTO. If not, please file a bug.
Oh interesting to know, didn’t realize LTO does that already. What exactly do I have to set for that ? Because I’ve seen various values for LTO=true, including “fat” and with multiple answers whether it makes a difference.
I’ve gotta be honest… I sorta stopped reading when I got to the part about the library being 1MB. Why would it be important to reduce the size? Maybe on some embedded device with a super-small amount of memory? Otherwise, when your watch has GBs of memory, why optimize for library size?
That aside… cargo bloat seems like a pretty cool tool!
A megabyte here, a megabyte there, soon you have Electron-level bloat, which everyone loves to hate. I don’t know about Federico, but as a library developer, I’m keenly aware that, at least judging by message board discussions, my potential users are harsh critics of bloat. And in my particular case, I don’t want anyone to decide that they’re not going to make their GUI accessible (e.g. to screen reader users) because my library was too bloated.
Your app isn’t alone in your phone. When it grows in size, it will cause other apps to be flushed out of memory, and when backgrounded, it will be flushed out sooner because it occupies memory.
Can more of this be done in
std? :)Are you aware of specific parts of std that are bloated due to generics?
I’m not an authority on this, but here’s what I know. The base overhead that std adds to each binary is primarily due to the backtrace functionality. Statically linking the code to walk the stack, read debug info, etc. adds considerable overhead. This code can be removed, but only using the unstable build-std feature of cargo and the unstable panic_immediate_abort feature of std, as documented in min-sized-rust.
I think most people complaining about the size would like to see some way that you can include only the part of the std which your program actually uses. Which IIRC is something we won’t see happening that fast.
It’s already there… With LTO, only the part of std used is included. Two parts of std are problematic for this: one is backtrace, as already mentioned. Another is formatting: it uses dynamic dispatch so unused code may be included due to analysis conservatism. Otherwise, all unused parts of std should be removed by LTO. If not, please file a bug.
Oh interesting to know, didn’t realize LTO does that already. What exactly do I have to set for that ? Because I’ve seen various values for
LTO=true, including “fat” and with multiple answers whether it makes a difference.