osstreams cause code bloat #168
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I recently added the framework to a cpp project which was relatively empty.
Code size was around 20-30kB . Then I compiled the framework and the code size grew by factor of 10 (even for the mission code with optimized code).
I dumped the sections with the linker flags
-Wl,-Map=irgendeintollername.mapand found out something interesting
Here is an excerpt from
.text(code)https://en.cppreference.com/w/cpp/locale/money_put hmm sounds nice but not too useful for a satellite :-)
There were countless of these sections related to osstream.
It also bloats .rodata (read-only data)
Now why is my code bloated even though I did not use the osstream?
The answer might be the following code
which is necessary as a forward declaration for all
ostreamcalls in the code.The compiler propably compiles everything mandatory for osstreams to work in addition to the printf functions which are not so friendly to the code size (the reason many manufacturers supply smaller printf functions for example, of course there is not such a thing for ostreams)
I think if reducing the code size is a goal, the best way propably to offer an alternative to ostreams. This would propably mean a heavy use of preprocessor defines. I am actually curious what happens if we wrap all osstream usage in these defines and compile the framework without it..
Might try that out in the future. This can propably achieved with a python/sed script which looks for sif::info / sif::debug / sif::error / std::endl occurences and puts the preprocessor define above and below it
I cab look into this after the state of the KSat fork and the main branch are (practically) equal because I already wrote a script to exclude ostream integration to test the difference. The first step is to write
FSFW_INFO,FSFW_DEBUG,FSFW_WARNINGandFSFW_ERRORprint implementations.