[PATCH] attempt to reduce size in readlink
Rob Landley
rob at landley.net
Fri Sep 16 16:14:16 UTC 2005
On Friday 16 September 2005 06:45, Tito wrote:
> Hi,
> this is just a proposal to reduce size of readlink.
> I personally don't like this coding style so much,
> so Rob it is up to you if you want to apply it.
> Size reduction is:
> text data bss dec hex filename
> 98 0 0 98 62 debianutils/readlink.o.orig_with_f
> 88 0 0 88 58 debianutils/readlink.o.new_with_f
>
> 76 0 0 76 4c debianutils/readlink.o.orig_no_f
> 46 0 0 46 2e debianutils/readlink.o.new_no_f
>
> Let me know what you think about it...
>
> Ciao,
> Tito
You shouldn't need an #ifdef around #include files. Does that really save
space?
Hmmm... Eliminating all the option parsing code when there are no options is
indeed cool, but you're right that it seems like there should be a better
way...
Off the top of my head I can figure out how to have a single code path
probably evaluate to the same code (with a compiler that can do constant
propogation, anyway, and yes I'm thinking "ulong opt = ENABLE ? getopt() :
0") for everything except optind. That side-effect of bb_getopt_ulflags() is
a bit tough to optimize away except via brute force like this patch does...
Lemme ruminate on this one a bit. (By which I mean "lunchtime".)
P.S. Why does the _big_ version get smaller? I checked and made sure that
ENABLE ? "f" : "" did _not_ include both strings. On gcc 3.3.5, anyway...
What compiler version are you using? (It would be nice to nail down which
gcc versions are broken about including constant strings that the calls to
are optimized out...)
Rob
More information about the busybox
mailing list