This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH] getopt.c: use integer-only function fiprintf() to save code space
- From: Craig Howland <howland at LGSInnovations dot com>
- To: newlib at sourceware dot org
- Date: Fri, 08 Nov 2013 12:45:40 -0500
- Subject: Re: [PATCH] getopt.c: use integer-only function fiprintf() to save code space
- Authentication-results: sourceware.org; auth=none
- References: <527D1803 dot 9000101 at op dot pl>
On 11/08/2013 11:57 AM, Freddie Chopin wrote:
Since size is the motivation for changing, so what if it is more clumsy?
On MicroBlaze, _fputs_r is 284 bytes versus 7720 for _vfiprintf_r. (Quoting the
size for the object files which include those functions.) This method could
also have the potential advantage of not pulling in fiprintf for people who are
using fprintf--which would be a possible hidden cost of this change. (There is
also an intermediate case where it could reduce the cost increase from the
addition of fiprint to the addition of fputs.)
It's an interesting question as to which approach would be faster.
(fputs() is much simpler, but the additional function call overhead is hard to
judge without an experiment. But I'd guess fputs() would probably be faster, as
well as smaller.)
I'd say go all the way. It would, however rate a comment in the file
explaining the clumsiness.
If you use getopt() (or any variant of this functionality) it pulls in
fprintf() to do output to stderr in case of error. As getopt() does not deal
with anything but strings or characters, it's much better to use fiprintf(),
which is MUCH smaller than fprintf() - about 2.8kB for _vfiprintf_r() vs.
6.5kB for _vfiprintf_r(), not counting any support data/functions (like 4.5kB
_dtoa_r()), ARMv7-M. If your program does not use fprintf() just using getopt
increases the size of the executable by 20kB (size of getopt() alone is ~2kB).
Let's not forget RAM use, which is smaller in fiprintf().
Actually I think that the output could be done with fputs() and fputc() only,
but to do that I'd first like your opinion - there's no actual formatting
(like changing the width or whatever), just displaying. This would be a bit
clumsy (2-7 calls to fputs()/fputc() in place of single f[i]printf()), but
still much MUCH smaller.