From owner-svn-src-head@FreeBSD.ORG Sun Jun 14 18:46:10 2015 Return-Path: Delivered-To: svn-src-head@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 679AD798 for ; Sun, 14 Jun 2015 18:46:10 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23B37887 for ; Sun, 14 Jun 2015 18:46:09 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4823F20DE6 for ; Sun, 14 Jun 2015 14:46:08 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sun, 14 Jun 2015 14:46:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=6dAEuUUDpP+yrHb6Ybshd3MR5Iw=; b=QuAZs0 7yhDzSoV1jWkVESsgOaf2nGz5srylqyAxsEozn+ezPLkcl+5pn+vyyhNcw+hQX2s sRxdTHAvR7XJTq8eRl2FqvmD2eAH1vG0Rwd7HmU+Y2PvfN51E5TNWVj3GDnZayGL K99pH+nfyXUCwmge7Kgf2Xd/9hbrK1hz1dPs0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=6dAEuUUDpP+yrHb 6Ybshd3MR5Iw=; b=ErTuN5x/yndx0qs3FH22KHQplzcjvRC2qC5QEMttzDzaTMb qXlr9hWdSSPXTRpZbwBVD0KI1UUxqsrwGO+ybERoQErd+XvuVwKVKLmac9EdYJvA IejTRBjdh0vGqXxIIPOrY+1aP4yVTE0EO+CE7n1mhNVUnV7CT0KY0FZ7bvlk= X-Sasl-enc: HeDuzsFtp7Dx07YZ0FhnyobKMpsyE/+Flsd4GXaJIbZV 1434307567 Received: from [192.168.1.64] (unknown [94.194.112.103]) by mail.messagingengine.com (Postfix) with ESMTPA id B9992680141; Sun, 14 Jun 2015 14:46:06 -0400 (EDT) Message-ID: <557DCBED.2010804@fastmail.net> Date: Sun, 14 Jun 2015 19:46:05 +0100 From: Bruce Simpson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Steve Kargl CC: Slawa Olhovchenkov , Craig Rodrigues , Marcel Moolenaar , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , Marcel Moolenaar , "src-committers@freebsd.org" Subject: Re: svn commit: r284198 - head/bin/ls References: <201506100127.t5A1RdX6051959@svn.freebsd.org> <20150612204309.11dd3391@kan> <20150613024916.GA98218@troutmask.apl.washington.edu> <1434208622.1415.57.camel@freebsd.org> <557C661F.8080104@freebsd.org> <860017ED-D754-450C-865D-2D81A30C2212@xcllnt.net> <20150614100045.GF58397@zxy.spb.ru> <557D55CB.5050009@fastmail.net> <20150614171031.GA5857@troutmask.apl.washington.edu> In-Reply-To: <20150614171031.GA5857@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 18:46:10 -0000 On 14/06/2015 18:10, Steve Kargl wrote: > On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote: >> >> But I have yet to see a coherent argument here -- size(1) numbers, RSS >> figures etc. -- about how it allegedly adds bloat. Most of what I've >> seen so far is POLA, NIH resistance, and hand-wavery. >> > > It is not alleged. I actaully measured the bloat libxo > caused when w(1) was converted. ... > Here's the bloat with ls(1) ... Steve, that's still less than one 4KB page. OK, so I find it difficult to believe -- in this day and age of pipeline-saving CMOV instructions -- that the overhead is as large as ~2800 bytes, where I would have expected roughly half that. But not knowing what compile options you used, or having information about sizes (and working sets - just listing file sizes is hand waving) across the libxo modified binaries, this still doesn't give a complete picture of the relative cost of the feature. However, that's still a very modest increase, considering the architectural scope of the libxo change and what it provides. Warner suggests that for some targets it is too much, and he might have a point. But if you look at That Other Operating System, this is generally dealt with there by deploying something like BusyBox instead. I can understand why we don't want to go down that road -- in my experience, the choice of BusyBox sacrifices too much usability -- and would support a WITH_LIBXO for that reason alone. The extra bytes might even disappear in the noise after crunchgen. I think it is also fair that the people who advocated for this in the beginning (not I, though I support it in principle) and did the work (not I either, ENOTIME) should have done this work up front. I've had to do it to justify similar changes in other projects.