From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 20 14:45:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEDD816A4CE for ; Sat, 20 Mar 2004 14:45:06 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9523143D1D for ; Sat, 20 Mar 2004 14:45:06 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i2KMj5LP002241 for ; Sat, 20 Mar 2004 17:45:05 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sat, 20 Mar 2004 17:45:04 -0500 To: hackers@FreeBSD.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Adventures with gcc: code vs object-code size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 22:45:07 -0000 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 = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu