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.
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
