Date: Tue, 18 Nov 2003 20:12:12 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: dyson@iquest.net, current@freebsd.org Subject: Re: Unfortunate dynamic linking for everything Message-ID: <p0600202dbbe06aca44fc@[128.113.24.47]> In-Reply-To: <200311181307.hAID7uHa032514@dyson.jdyson.com> References: <200311181307.hAID7uHa032514@dyson.jdyson.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 8:07 AM -0500 11/18/03, dyson@iquest.net wrote: > > It really doesn't make sense to arbitrarily cut-off a > discussion especially when a decision might be incorrect. All I wanted to cut off was the claim that this decision had not been discussed publicly before. It was also annoying that most the recent complaints (before your message) were issues that had been explicitly discussed and addressed before the decision had been reached. Many people seem to be complaining on what they think we did, as opposed to what we actually did. > If there hadn't been a noticed increase in cost by using > all-shared-libs, then the measurements were done > incorrectly. If the decision is made based upon allowing > for 1.5X (at least) times increase in fork/exec times, and > larger memory usage (due to sparse allocations), ... I do remember some comments about benchmarks, and it was true that the all-dynamic bin/sbin does come out slower. I don't remember if the benchmarks were ours or from NetBSD's investigation. However, I think we measured increase in overall time for some set of commands, instead of "increase in the fork() routine". Thus, the penalty observed was much less than 50%. I think it was under 2%, but I don't remember the exact number. When we're dealing with a 100% increase in the cost of compiling something with the newer gcc, the increase due to this change seemed pretty insignificant... It is probably true that there are several commands where we would see a worthwhile performance benefit by static linking, and which have no need for things like dynamic PAM modules. But commands which care about userids or group information would need to stay dynamic (IMO), and I think that means all shells. Also, when it comes to security fixes, it would be nice for binary upgrades if all we had to do was replace one library, instead of replacing every command which is statically-linked with the problem routine. The announcement of this change may have played up disk-savings more than it should have, because we weren't doing this to save disk space. It was just that the disk savings were a very nice side-effect. It's pretty rare that we can talk about the system getting smaller! :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0600202dbbe06aca44fc>