Date: Sun, 21 Mar 2004 02:20:13 -0500 From: "Matt Emmerton" <matt@gsicomp.on.ca> To: <hackers@freebsd.org>, "Garance A Drosihn" <drosih@rpi.edu> Subject: Re: Adventures with gcc: code vs object-code size Message-ID: <002f01c40f14$f4406540$1200a8c0@gsicomp.on.ca> References: <p0602044cbc827481888c@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Garance A Drosihn" <drosih@rpi.edu> To: <hackers@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002f01c40f14$f4406540$1200a8c0>