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.

--
Garance Alistair Drosehn            =   [EMAIL PROTECTED]
Senior Systems Programmer           or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute    or  [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to