Current Minimal Binary Size

Ed Tanous ed.tanous at intel.com
Sat Sep 14 07:00:50 AEST 2019


On 9/13/19 5:52 AM, Wilfred Smith wrote:
> These values may be of use to someone else. I’ve been putting energy into reducing code size lately. The following are all with -Os enabled.
> 
> Smallest .SO (one function with no statements in the body) - 8.2K
> Smallest executable (main with only a return statement) - 12K
> Smallest executable with a printf and return - 14K
> Smallest executable with a std::cout and return - 103K

This is exactly why this rule exists:
https://github.com/openbmc/docs/blob/master/cpp-style-and-conventions.md#iostream

Unfortunately not everyone is consistent about it (including myself).
The components that pull iostreams in should definitely be moved to
something like std::format, printf, or fmt in the future.

> 
> For comparison:
>  Smallest executable with a printf and return on x86-64 - 8.2K
>  Smallest executable with a std::cout and return on x86-64 - 42K
> 
> 

It would be interesting data to load all of the above in a real OpenBMC
rootfs, and compare the size again in this tool (or something similar)
https://github.com/openbmc/openbmc-tools/blob/master/edtanous/rootfs_size.py

Just because the file is "bigger" when compiled doesn't mean that it's
actually taking up space post-squashfs.  A lot of the code that's common
across applications code gets de-duplicated when the filesystem is built.

That's not to say it's not something that could be improved on, but it
might be a smaller issue than it seems.


More information about the openbmc mailing list