This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] getopt.c: use integer-only function fiprintf() to save code space


On 11/08/2013 11:57 AM, Freddie Chopin wrote:
Hello!

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.

Regards,
FCh
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.
                Craig


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]