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