Adventures with gcc: code vs object-code size

[Matt Emmerton]

----- Original Message ----- 
From: "Garance A Drosihn" <drosih at rpi.edu>
To: <hackers at freebsd.org>
Sent: Saturday, March 20, 2004 5:45 PM
Subject: Adventures with gcc: code vs object-code size


> I have written a fairly major set of changes to the `ps' command,
> which is available as:
> http://people.freebsd.org/~gad/ps-susv3.diff
>
> Debate/discussion about the changes themselves actual changes should
> be going on in the freebsd-standards mailing list.  So for purposes
> of this mailing list, please ignore most of that.
>
> But while doing it, I was somewhat obsessed about making sure that
> my changes wouldn't cause a dramatic increase in the size of the
> executable for `ps'.  Due to that, I tripped over one example of
> "code" vs "object-code produced" which makes no sense to me.  So,
> consider just this section of the update (with some reformatting
> so it is easy to see the code):
>
> char elemcopy[PATH_MAX];
>     ...do stuff...
> #if !defined(ADD_PS_LISTRESET)
> inf->addelem(inf, elemcopy);
> #else
> /*
> * We now have a single element.  Add it to the
> * list, unless the element is ":".  In that case,
> * reset the list so previous entries are ignored.
> */
> if (strcmp(elemcopy, ":") == 0)
> inf->count = 0;
> else
> inf->addelem(inf, elemcopy);
> #endif
>
> Now, here is what I noticed:
>
> * XXX - Adding this check increases the total size of `ps' by
> * 3940 bytes on i386!  That's 12% of the entire program!
> * { using gcc (GCC) 3.3.3 [FreeBSD] 20031106 }
> *
> * When compiling for sparc, adding this option causes NO
> * change in the size of the `ps' executable.  And on alpha,
> * adding this option adds only 8 bytes to the executable.
>
> So, by adding one call to strcmp() to check for a ":" string, I end
> up with /bin/ps (the stripped-object-file) which has grown by  12.6% !!
> This is for a program which is almost 2500 lines spread out over
> 5 '.c'-files.  How is that possible?  What am I missing here?
>
> I am not a compilier guru, so I suspect it would take me hours to
> pin this down.  I don't want to do that, so I'm wondering if anyone
> understands how such a minor code-change can POSSIBLY cause such a
> huge change in resulting object file...  I also wonder if this same
> issue pops up in other programs, too.

I don't know why the code bloats so much on i386, but I do question the use
of strcmp() for a single-character compare.
Something like the following would probably be better (and would avoid your
problem):

if (elemcopy[0] == ':')
  inf->count = 0;
else
  inf->addelem(inf, elemcopy);

--
Matt Emmerton